Java并发基础之Compare And Swap/Set(CAS)

　　什么是 CAS？CAS（Compare And Swap/Set）比较并交换， CAS 算法的过程是这样：它包含 3 个参数CAS(V,E,N)。 V 表示待更新的变量(内存值)， E 表示预期值(旧的)， N 表示新值。当且仅当 V 值等于 E 值时，才会将 V 的值设为 N，如果 V 值和 E 值不同，则说明已经有其他线程做了更新，则当前线程什么都不做。最后， CAS 返回当前 V 的真实值。

　　用伪代码表示，如下：

　　　　if(V==E){

　　　　　　V=N;

　　　　}else{

　　　　　　//do nothing

　　　　}

　　CAS算法从逻辑上上很简单，同时它却是整个JUC体系最核心、最基础理论。CAS 操作是抱着乐观的态度进行的(乐观锁)，它总是认为自己可以成功完成操作。 当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。基于这样的原理，CAS 操作即使没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。

　　从逻辑上可这样理解：当某个线程进入含CAS算法的方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由 JVM 从等待队列中选择一个另一个线程进入。(对于自旋锁等概念参考Java锁概念的分类总结 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com))

　　以Semaphore为例，看看CAS算法的使用：

　　　　

　　CAS 算法实现一个重要前提需要取出内存中某时刻的数据，而在下时刻比较并替换，那么在这个时间差内数据可能发生变化。比如说一个线程 one 从内存位置 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且two 进行了一些操作变成了 B，然后 two 又将 V 位置的数据变成 A，这时候线程 one 进行 CAS 操作发现内存中仍然是 A，然后 one 操作成功。尽管线程 one 的 CAS 操作成功，但是不代表这个过程就是没有问题的。这就是CAS 导致的“ABA 问题”。

　　对于“ABA问题”如何解决呢？部分乐观锁的实现是通过版本号（version）的方式来解决 ABA 问题，乐观锁每次在执行数据的修改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行+1 操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现 ABA 问题，因为版本号只会增加不会减少。具体实现利用AtomicStampedReference类。

　　下面重现ABA问题，然后示例AtomicStampedReference解决这个问题：

　　　　

　　案例中线程“张三”将10改为11后再改回10，线程“李四”做CAS操作是发现预期值是10于是改为12。两个线程都没有错，但这就是问题——就好比某人挪用公款之后在未发现之前将钱还了回来，这个钱还是原来的公款么？看AtomicStampedReference如何解决。

　　　　

　　根据测试结果可以看到：AtomicStampedReference里面增加了一个时间戳，每次CAS操作都对版本号进行了设置。出现了“ABA的问题”但是根据版本号可以知道修改的A已经不是之前的A了。

　　继续探究AtomicStampedReference中CAS方法：