分析JUC源码必须了解CAS

什么是CAS?JDK里Unsafe类的一个API：compareAndSwap,即比较和交换，它是一个native方法，底层C++实现，包括compareAndSwapObject，compareAndSwapInt和compareAndSwapLong，方法有四个参数，对象，待修改的属性在对象里的偏移量A(可以理解为获取属性的get方法或者指针)，期望值B，修改后的值V;方法的执行流程：先通过A从主存获取最新的值C,拿C和期望值B进行比较，如果C==B相等，即将属性值修改为V,返回true,如果C != B,则不修改属性的值，返回false.

并发包concurrent很大程度是基于CAS实现的，比如JDK8的ConcurrentHashMap就是利用CAS和synchronized实现并发安全的，另外AQS和原子操作类都用到了CAS。我们分析并发包源码，必须了解CAS,更精确的说，必须了解Unsafe的API,UnSafe作为JVM一个操作底层硬件资源的后门，了解它后，才不至于对concurrent源码一头雾水，望而却步。

下面简单分析下原子操作类AtomicInteger 中CAS的使用；

    public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;

    // setup to use Unsafe.compareAndSwapInt for updates
    // 使用CAS更新值
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            // 通过unsafe获取属性value的偏移量（每个属性的偏移量是不变的）
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    // 属性value,也就是我们需要更新的属性
    private volatile int value;

涉及CAS的一个方法：unsafe.compareAndSwapInt(this, valueOffset, expect, update)，this表示当前对象，也就是AtomicInteger的当前对象，我们下面测试代码里面的b,valueOffset就是对象里面的属性value的偏移量，expect期望值，update待修改的值。

     /**
     * Atomically sets the value to the given updated value
     * if the current value {@code ==} the expected value.
     *
     * @param expect the expected value  期望值
     * @param update the new value  新值
     * @return {@code true} if successful. False return indicates that
     * the actual value was not equal to the expected value.
     */
    public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

测试：

    public class Test {

    public static void main(String[] args) {
        AtomicInteger b = new AtomicInteger(10);
        System.out.println("修改前："+b.get());

        // 成功修改场景
        Boolean b1 = b.compareAndSet(10,12);
        System.out.println("第一次是否成功b1：" + b1);
        System.out.println("第一次修改后：" + b.get());

        // 失败修改场景
        Boolean b2 = b.compareAndSet(13,15);
        System.out.println("第一次修改是否成功b2："+ b2);
        System.out.println("第二次修改后：" + b.get());
    }

}

打印结果如下，第一次修改，b的原值和期望值都是10,修改成功，修改后值是12，第二次修改，期望值是13，和b的现值12不相等，所以修改失败，b值还是第一次修改后的值12：

修改前：10
第一次修改是否成功b1：true
第一次修改后：12
第一次修改是否成功b2：false
第二次修改后：12

CAS是乐观锁技术（每次去拿数据的时候都认为别人不会修改，所以不会上锁），当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。相对于对于 synchronized 这种阻塞算法，CAS是非阻塞算法的一种常见实现。

CAS缺点：　

 1. ABA问题：什么是ABA问题，假设一个属性原值是A,线程1对它修改为B后又把它修改为A,此时线程2再去修改它，因为它还是值A,线程2认为它是没改变的，修改成功。不过我们的业务场景，我觉得ABA一般也没啥影响。可以使用AtomicStampedReference和AtomicMarkableReference解决ABA问题，前者记录属性值改变的次数，后者记录属性值是否改变。

2. 循环时间长开销大：自旋CAS（不成功，就一直循环执行，直到成功，比如ConcurrentHashMap里方法fullAddCount的for (;;) 代码块）如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

3. 只能保证一个共享变量的原子操作：当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

 

CAS与Synchronized的使用情景：　　　

1、对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。

2、对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

补充： synchronized在jdk1.6之后，已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

 

参考：

Java并发问题--乐观锁与悲观锁以及乐观锁的一种实现方式-CAS