CAS(CompareAndSwap) 深入源码解析
CAS：Compare and Swap，比较并交换。它最底层用的是CUP并发原语
CAS有3个操作数，内存地址中的值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
java.util.concurrent包中借助CAS实现了区别于synchronouse同步锁的一种乐观锁。
CAS并发原语体现在JAVA语言中就是sun.misc.Unsafe类中的各个方法。调用UnSafe类中的CAS方法，JVM会帮我们实现出CAS汇编指令。这是一种完全依赖于硬件的功能，通过它实现了原子操作。再次强调，由于CAS是一种系统原语，原语属于操作系统用语范畴，是由若干条指令组成的，用于完成某个功能的一个过程，并且原语的执行必须是连续的，在执行过程中不允许中断，也就是说CAS是一条CPU的原子指令，不会造成所谓的数据不一致问题。
java.util.concurrent.atomic系列方法就是依赖于CAS
CAS底层原理
image.png
原理1.Unsafe是CAS的核心类，由于Java方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe类相当于Java留的一个后门，基于该类可以直接操作特定内存的数据。Unsafe类存在于jdk的sun.misc包中，其内部方法操作可以像C的指针一样直接操作内存，CAS操作的执行依赖于Unsafe类的方法。
注意Unsafe类中的所在方法都是native修饰的,也就是送Unsafe类中的方法都直接调用操作系统底层资源执行相应任务,故可以直接比较内存值和期望值.而其value值被volatile修饰后保证了其可见性,一旦发生偏移就会通知本地内存
原理2.变量valueOffset，表示该变量值在内存中的偏移地址，因为Unsafe就是根据内存偏移地址获取数据的。
AtomicInteger里的getAndIncrement方法调用了unsafe里的getAndAddInt方法
原理3. 变量value用volatile修饰，保证了多线程之间内存的可见性
unsafe类底层👇
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
public final native boolean
compareAndSwapInt(Object var1, long var2, int var4, int var5);
/*
var1 Atomiclntegler对象本身。
var2该对象值得引用地址。
var4 需要变动的数量。
var5是用过var1 var2找出的主内存中真实的值。
用该对象当前的值与var5比较：
如果相同，更新var5+var4并且返回true，如果不同，继续取值然后再比较，直到更新完成。
*/
最底层的this.compareAndSwapInt(var1, var2, var5, var5 + var4));
依赖于👇,native本地方法,它是cpu原语
image.png
CAS的缺点:
- 循环时间长开销很大。(unsafe底层如果不匹配成功会一直do-while下去,一直不成功会造成很大的cpu开销)
- 只能保证一个共享变量的原子操作。(一次只能保证一个对象)
- 可能产生ABA问题
ABA问题
CAS算法实现一个重要前提需要取出内存中某时刻的数据并在当下时刻比较并替换，那么在这个时间差类会导致数据的变化。
比如说有线程one,two两个线程,one线程较慢需要十秒钟,two线程较快尽需两秒,一个线程one从内存位置中取出A，这时候另一个线程two也从内存中取出A，并且线程two进行了一些操作将值变成了B，然后线程内有一些其他操作two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后线程one操作成功。
尽管线程one的CAS操作成功，但是不代表这个过程就是没有问题的。因为one得到的这个内存中的值已经发生了许多问题.
ABA问题如何规避?
https://www.jianshu.com/p/cdb8452d9dd6
