【Java并发编程】线程安全-CAS原理
原理
CAS（compare-and-swap）是并发编程中用于实现线程同步的一种原子指令，可以用以下伪代码描述：
cas（loc，expectedV， newValue） {
if(getValue(loc) == expectedV)
setValue(loc, newValue)
else try again or fail
}
整个CAS操作是一个原子操作，其中loc代表该内存位置，expectedV代表该内存位置内部的期望值。
CAS操作会将当前内存位置的值与期望值比较，如果匹配，那么处理器会自动将该内存位置的值更新为新值newValue，并返回 true;如果不相匹配， 处理器不做任何操作，并返回 false。
使用CAS实现乐观锁，一般需要配合自旋，步骤大致如下:
- 获取字段的期望值expectedV
- 计算需要替换的结果值newValue
- cas操作（原子操作：比较oldValue与当前内存地址中的值是否相等，成功赋值结束循环，失败重新开始循环）
do
{
expectedV = getValue(loc);
newValue = ... //计算newValue
} while(cas(loc，expectedV， newValue))
从语义上理解：执行这段临界区代码的时候(注意只能针对单个共享变量),乐观地认为不会有其他线程修改变量。其实可以看做把获取期望值 — cas操作这段代码加锁了，或者说相当于给地址loc加锁，只不过加的是乐观锁
当然CAS作为一种基础的原子操作，不仅仅只有上面这一种用法，下一节会介绍更多CAS在Java中的用法
Java层面的CAS
在java层面，CAS对应的是Unsafe类中的三个 “比较并交换”的原子方法
Unsafe 提供的 CAS 方法，直接通过 native 方式(封装 C++代码)调用了底层的 CPU 指令 cmpxchg，该指令具有原子性。
- CAS方法会有四个字段，包括：字段的包装对象、字段内存位置（在包装对象内部的偏移量）、期望原值和新值
- 这些方法进行以下原子操作：会将当前内存位置的值与期望值比较，如果匹配，那么处理器会自动将该内存位置的值更新为新值，并返回 true;如果不相匹配， 处理器不做任何操作，并返回 false。
public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object update);
public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update);
public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);
CAS在Java中具有广泛的应用：
在 java.util.concurrent.atomic 包的原子类如 AtomicXXX 中，都使用了 CAS 保障对数字成员 进行操作的原子性。
java.util.concurrent 的大多数类(包括显式锁、并发容器)都基于 AQS 和 AtomicXXX 实现， 而 AQS 通过 CAS 保障其内部双向队列头部、尾部操作的原子性。
Atomic类型中的CAS
AtomicInteger是常用的一个原子类，它的自增方法getAndIncrement就用到了CAS+自旋，它调用了unsafe的getAddInt方法，而getAddInt中的compareAndSwapInt方法是native方法**
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
//CAS+自旋
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;
}
ConcurrentHashmap中的CAS
CMH的源码中也大量使用到了CAS，例如，当向CMH的桶数组插入元素时，如果发现当前这个桶不存在node，就要初始化一个新node，但是为了避免创建时的并发问题，要利用CAS进行创建。
使用CAS创建node也很好理解，因为创建操作如果失败了就直接跳过进行之后操作，失败的线程消耗的也就是一次CAS操作，比起重量级锁的用户内核态的切换损耗小
它最终使用的就是compareAndSwapObject，其中内存首地址是桶数组，偏移量是利用hash计算出来的，期望值应该是null，新值应该是new Node。
Node oldNode;
if ((oldNode = getAt(offset)) == null) {
if ( !cas(nodes[], offset, null ,new Node()) {
... (break;)
}
}
CAS的问题：
ABA问题
ABA问题是指在CAS操作时，其他线程将变量值A改为了B，但是又改回了A，等到本线程使用期望值A与当前变量进行比较时，发现变量A没有变，于是CAS操作成功，但是实际上该值已经被其他线程改变过，这与乐观锁的设计思想不符合。
解决方法：每次变量更新的时候把变量的版本号加1，那么A-B-A就会变成A1-B2-A3，只要变量被某一线程修改过，改变量对应的版本号就会发生递增变化，从而解决了ABA问题。其实也就是把版本号也作为CAS比较的一部分了
在JDK的java.util.concurrent.atomic包中提供了AtomicStampedReference来解决ABA问题，该类的compareAndSet是该类的核心方法
当然，ABA问题不见得都会引发逻辑错误，得看具体场景
CAS只能者嗯对单变量
CAS的原子操作只能针对一个共享变量，假如需要针对多个变量进行原子操作也是可以解决的。
解决方法：1. 可以加锁来解决。2 .封装成对象类解决。
CAS导致自旋消耗
使用CAS+自旋的方式实现乐观锁，当多个线程争夺同一个资源时，如果某些线程自旋一直不成功，将会一直占用CPU。
解决方法：破坏掉for死循环，当超过一定时间或者一定次数时，return退出。
JDK8新增的LongAddr,和ConcurrentHashMap类似的方法。当多个线程竞争时，将粒度变小，将一个变量拆分为多个变量，达到多个线程访问多个资源的效果，最后再调用sum把它合起来。
在部分 CPU 平台上存在“总线风暴”问题
CAS 操作和 volatile 一样，都会调用 lock，也需要 CPU 进行通过 MESI 协议各个内核的“Cache 一致性”， 会通过 CPU 的 BUS 总线发送大量 MESI 协议相关的消息，产生“Cache 一致性流量”。因为总线 被设计为固定的“通信能力”，如果 Cache 一致性流量过大，总线将成为瓶颈，这就是所谓的“总线风暴”。
如何提升 CAS 性能?
- 是以空间换时间，分散竞争热点。较为常见的方案为:
(1)分散操作热点，使用 LongAdder 替代基础原子类 AtomicLong，LongAdder 将单个 CAS 热点(value 值)的分散到一个 cells 数组中。
(2)使用队列削峰，将发生 CAS 争用的线程加入一个队列中排队，降低 CAS 争用的激烈程 度。JUC 中非常重要的基础类 AQS(抽象队列同步器)就是这么做的。
- 使用线程本地变量，从根本上避免竞争。