CAS算法
目录
概述
CAS（Compare-and-Swap），即比较并替换，是一种实现并发算法时常用到的技术，Java并发包中的很多类都使用了CAS技术。CAS也是现在面试经常问的问题，本文将深入的介绍CAS的原理。
案例
介绍CAS之前，我们先来看一个例子。
public class VolatileTest {
public static volatile int race = 0;
private static final int THREADS_COUNT = 20;
public static void increase() {
race++;
}
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[THREADS_COUNT];
for (int i = 0; i < THREADS_COUNT; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
increase();
}
}
});
threads[i].start();
}
while (Thread.activeCount() > 1) {
Thread.yield();
}
System.out.println(race);
}
}
这个例子有些网友反馈会进入死循环，我后面也发现了，在IDEA的RUN模式下确实会陷入死循环，通过 Thread.currentThread().getThreadGroup().list(); 代码可以打印出当前的线程情况如下：
java.lang.ThreadGroup[name=main,maxpri=10]
Thread[main,5,main]
Thread[Monitor Ctrl-Break,5,main]
可以看到，除了Main方法线程后，还有一个Monitor Ctrl-Break线程，这个线程是IDEA用来监控Ctrl-Break中断信号的线程。
解决死循环的办法：如果是IDEA，可以使用DEBUG模式运行就可以，或者使用下面这段代码。
import java.util.concurrent.CountDownLatch;
public class VolatileTest {
public static volatile int race = 0;
private static final int THREADS_COUNT = 20;
private static CountDownLatch countDownLatch = new CountDownLatch(THREADS_COUNT);
public static void increase() {
race++;
}
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[THREADS_COUNT];
for (int i = 0; i < THREADS_COUNT; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
increase();
}
countDownLatch.countDown();
}
});
threads[i].start();
}
countDownLatch.await();
System.out.println(race);
}
}
上面这个例子在volatile关键字详解文中用过，我们知道，运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序，输出的结果都不一样，都是一个小于200000的数字。
通过分析字节码我们知道，这是因为volatile只能保证可见性，无法保证原子性，而自增操作并不是一个原子操作（如下图所示），在并发的情况下，putstatic指令可能把较小的race值同步回主内存之中，导致我们每次都无法获得想要的结果。那么，应该怎么解决这个问题了？
解决方法：
首先我们想到的是用synchronized来修饰increase方法。
使用synchronized修饰后，increase方法变成了一个原子操作，因此是肯定能得到正确的结果。但是，我们知道，每次自增都进行加锁，性能可能会稍微差了点，有更好的方案吗？
答案当然是有的，这个时候我们可以使用Java并发包原子操作类（Atomic开头），例如以下代码。
我们将例子中的代码稍做修改：race改成使用AtomicInteger定义，“race++”改成使用“race.getAndIncrement()”，AtomicInteger.getAndIncrement()是原子操作，因此我们可以确保每次都可以获得正确的结果，并且在性能上有不错的提升（针对本例子，在JDK1.8.0_151下运行）。
通过方法调用，我们可以发现，getAndIncrement方法调用getAndAddInt方法，最后调用的是compareAndSwapInt方法，即本文的主角CAS，接下来我们开始介绍CAS。
getAndAddInt方法解析：拿到内存位置的最新值v，使用CAS尝试修将内存位置的值修改为目标值v+delta，如果修改失败，则获取该内存位置的新值v，然后继续尝试，直至修改成功。
CAS是什么？
CAS是英文单词CompareAndSwap的缩写，中文意思是：比较并替换。CAS需要有3个操作数：内存地址V，旧的预期值A，即将要更新的目标值B。
CAS指令执行时，当且仅当内存地址V的值与预期值A相等时，将内存地址V的值修改为B，否则就什么都不做。整个比较并替换的操作是一个原子操作。
源码分析
上面源码分析时，提到最后调用了compareAndSwapInt方法，接着继续深入探讨该方法，该方法在Unsafe中对应的源码如下。
可以看到调用了“Atomic::cmpxchg”方法，“Atomic::cmpxchg”方法在linux_x86和windows_x86的实现如下。
linux_x86的实现：
windows_x86的实现：
Atomic::cmpxchg方法解析：
mp是“os::is_MP()”的返回结果，“os::is_MP()”是一个内联函数，用来判断当前系统是否为多处理器。
如果当前系统是多处理器，该函数返回1。
否则，返回0。
LOCK_IF_MP(mp)会根据mp的值来决定是否为cmpxchg指令添加lock前缀。
如果通过mp判断当前系统是多处理器（即mp值为1），则为cmpxchg指令添加lock前缀。
否则，不加lock前缀。
这是一种优化手段，认为单处理器的环境没有必要添加lock前缀，只有在多核情况下才会添加lock前缀，因为lock会导致性能下降。cmpxchg是汇编指令，作用是比较并交换操作数。
intel手册对lock前缀的说明如下：
1.确保对内存的读-改-写操作原子执行。在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
2.禁止该指令与之前和之后的读和写指令重排序。
3.把写缓冲区中的所有数据刷新到内存中。
上面的第1点保证了CAS操作是一个原子操作，第2点和第3点所具有的内存屏障效果，保证了CAS同时具有volatile读和volatile写的内存语义。
CAS的缺点：
CAS虽然很高效的解决了原子操作问题，但是CAS仍然存在三大问题。
1.循环时间长开销很大。
2.只能保证一个变量的原子操作。
3.ABA问题。
1.循环时间长开销很大：
CAS 通常是配合无限循环一起使用的，我们可以看到 getAndAddInt 方法执行时，如果 CAS 失败，会一直进行尝试。如果 CAS 长时间一直不成功，可能会给 CPU 带来很大的开销。
2.只能保证一个变量的原子操作：
当对一个变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个变量操作时，CAS 目前无法直接保证操作的原子性。但是我们可以通过以下两种办法来解决：1）使用互斥锁来保证原子性；2）将多个变量封装成对象，通过 AtomicReference 来保证原子性。
3.什么是ABA问题？ABA问题怎么解决？
目录
CAS 的使用流程通常如下：1）首先从地址 V 读取值 A；2）根据 A 计算目标值 B；3）通过 CAS 以原子的方式将地址 V 中的值从 A 修改为 B。
但是在第1步中读取的值是A，并且在第3步修改成功了，我们就能说它的值在第1步和第3步之间没有被其他线程改变过了吗？
如果在这段期间它的值曾经被改成了B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA”问题。Java并发包为了解决这个问题，提供了一个带有标记的原子引用类“AtomicStampedReference”，它可以通过控制变量值的版本来保证CAS的正确性。因此，在使用CAS前要考虑清楚“ABA”问题是否会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效。
————————————————
以上内容原文链接：https://blog.csdn.net/v123411739/article/details/79561458
CAS的ABA问题
锁是用来做并发最简单的方式，当然代价也是最高的。
独占锁是一种悲观锁，synchronized就是一种独占锁；它假设最坏的情况，并且只有在确保其它线程不会造成干扰的情况下执行，会导致其它所有需要锁的线程挂起直到持有锁的线程释放锁。
所谓乐观锁就是每次不加锁,假设没有冲突而去完成某项操作;如果发生冲突了那就去重试，直到成功为止。
CAS(Compare And Swap)是一种有名的无锁算法。CAS算法是乐观锁的一种实现。CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B并返回true，否则返回false。
注:synchronized和ReentrantLock都是悲观锁。
注:什么时候使用悲观锁效率更高、什么时候使用乐观锁效率更高，要根据实际情况来判断选择。
提示:atomic中包下的类，采用的即为CAS乐观算法。
以AtomicInteger的public final int getAndSet(int newValue)方法，进行简单说明，
该方法是这样的:
其调用了Unsafe类的public final int getAndSetInt(Object var1, long var2, int var4)方法:
而该方法又do{…}while(…)循环调用了本地方法public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
注:至于Windows/Linux下public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5)本地
方法是如何实现的，推荐阅读https://blog.csdn.net/v123411739/article/details/79561458。
CAS(Compare And Swap)原理简述：
某一线程执行一个CAS逻辑(如上图线程A),如果中途有其他线程修改了共享变量的值(如:上图中线程A执行到笑脸那一刻时),导致这个线程的CAS逻辑运算后得到的值与期望结果不一致，那么这个线程会再次执行CAS逻辑(这里是一个do while循环),直到成功为止。
注:可能上图中某些地方写得并不规范，主要理解意思即可，不要在意细节。
ABA问题：
如图所示，线程A进行CAS逻辑，在从内存中获取到var值到开始进行逻辑之间（对应图中笑脸处）,会有一个时间差;如果刚好在这个时间差内，有其他某线程对var做了一系列的操作,但最后又恢复了var的值，即:出现“偷梁换柱”的情况;虽然此时线程A仍然能CAS成功，但是中间多出的那些过程仍然可能引发问题。
注:可能上图中某些地方写得并不规范，主要理解意思即可，不要在意细节。
注:上图A变为B再变回A,A的属性被修改了，如果程序此时刚好需要用上A的属性,那么就可能造成实际结果与理想结果不一致的情况。
注:根据实际情况，判断是否处理ABA问题。如果ABA问题并不会影响我们的业务结果，可以选择性处理或不处理;如果ABA会影响我们的业务结果的，这时就必须处理ABA问题了。
追注:对于AtomicInteger等,没有什么可修改的属性;且我们只在意其结果值，所以对于这些类来说，本身就算发生了ABA现象，也不会对原线程的结果造成什么影响。
解决ABA问题：
我们可以通过加一个标识来解决这个问题;即:所有要用到某一共享引用的线程，如果在用到该引用时，都对该引用对应的标识进行推进的话，那么CAS在进行“上图中笑脸前笑脸后”对比时，除了要对比原来的引用(上图中的A)外，还要对比标识的值是否一样，这样就解决了ABA问题。
注:可能上图中某些地方写得并不规范，主要理解意思即可，不要在意细节。
注:这个标识只有一个职责，那就是计数，我们并不拿其值做什么业务有关的操作。
注:各种乐观锁的实现中通常都会用版本戳version来标记对象，进而避免ABA问题。在Java中，
AtomicMarkableReference<V>、AtomicStampedReference<V>也实现了这个作用。
画黄线的英文的意思为:AtomicMarkableReference<V>、可以给一个引用标记上一个标记位，来保证原子性。AtomicStampedReference<V>可以给一个引用标记上一个整型的版本戳，来保证原子性。
注:个人感觉AtomicStampedReference<V>使用相对较多，下面也只简单介绍AtomicStampedReference<V>。
给出AtomicStampedReference<V>部分API:
注:更多细节详见API手册。
声明:下列示例均为笔者按照自己的理解敲的示例，如有不当之处，欢迎指正!
代码简单示例ABA问题的发生：
运行主函数，控制台输出结果为:
代码简单示例解决ABA问题的思路:
运行主函数，控制台输出结果为:
笔者将本人多线程一栏中博客涉及到的所有代码示例(Lock分开放在一个专门的项目、synchronized的代码附在该文章末尾)，放在GIT上了(链接见本文末)，这里先给出一个所涉及内容图：
参考视频
《Java多线程与并发实战视频课程》，齐毅
参考链接
https://www.cnblogs.com/onlywujun/articles/3529572.html
https://www.cnblogs.com/549294286/p/3766717.html
https://blog.csdn.net/v123411739/article/details/79561458
https://www.cnblogs.com/exceptioneye/p/5373498.html
多线程一栏所有测试示例代码，托管链接
https://github.com/JustryDeng/PublicRepository
4849
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
