转载

CAS解析

CAS：compare and swap，也有的叫做 compare and set；意思都差不多，翻译过来就是比较并交换或者比较并设值。

CAS包含三个值，内存地址（V)，预期值（A），新值（B）。先比较内存地址的值和预期的值是否相等，如果相等，就将新值赋在内存地址上，否则，不做任何处理。这种是乐观锁的思想。

CAS解析

源码解析

CAS操作在JUC中大量用到，在解析AQS那章中，我们也有提到。再回头看一下AQS中CAS的操作

protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }

这里是对AQS中state变量进行的CAS操作，要知道，很多同步类都是通过这个变量来实现线程安全的，所以在AQS中，首先要保证对state的赋值是线程安全的。

在java中，不论什么操作，只要他还是在Java api级别，就不能保证他一定是线程安全的，除非这个操作调用系统资源来支持。这里保证state线程安全是通过unsafe中的compareAndSwapInt方法来实现的，里面的参数stateOffset就是内存地址（V），expect是预期值（A），新值（B）。在unsafe中，大部分方法都是native的，而且unsafe可以直接操作系统的内存资源，不受jvm限制，通过它来保证线程安全，应该是稳了，但是unsafe类官方是不建议用的，咱们平时开发大部分时候也用不着，需要的操作，jdk已经帮我们封装好了。

CAS的问题

CAS虽然看起来很完美，可以在原子级别保证一个变量的线程安全，但是它有时候也会出问题，比如著名的ABA问题。

ABA问题：我们都知道CAS操作是先比较A的预期值和内存地址中的值是否相同，如果相同就认为此时没有其他线程修改A值，但是一定是这样吗？假如一个线程读取到A值，此时有另外一个线程将A值改成了B，然后又将B改回了A，这时比较A和预期值是相同的，就认为A值没有被改变过。为了解决ABA的问题，可以使用版本号，每次修改变量，都在这个变量的版本号上加1，这样，刚刚A->B->A，虽然A的值没变，但是它的版本号已经变了，再判断版本号就会发现此时的A已经被别人偷偷改过了。

CAS还有一个性能问题，在大部分使用CAS的时候，都是配合自旋来使用，这里的自旋，你可以理解为for(;;)这样的无限循环，我们在jdk源码中找一处来看看

public final int getAndSet(int newValue) {
        for (;;) {
            int current = get();
            if (compareAndSet(current, newValue))
                return current;
        }
    }

这AtomicInteger类中getAndSet方法，这是jdk1.7中的代码，在1.8中换成了另外一种写法，意思都是自旋加CAS，jdk1.7中自旋在AtomicInteger里，而jdk1.8调用了unsafe中getAndSetInt方法，在这个方法中自旋，有兴趣的话可以去看看1.8中的源码。

平时我们开发过程中，如果碰到系统蹦了，大部分人可能第一时间就会想到代码里是不是出现死循环了，当出现死循环时，会占用系统大量资源，造成系统崩溃。在这里我们看到源码中的自旋就是当CAS成功时，才会return。当然也不会出现CAS一直失败的情况，那几率也太小了。因此CAS带来的性能问题也是需要考虑的。但是从某种意思上来说，这个自旋也是CAS的优势，自旋算是一种非阻塞算法，相对于其他阻塞算法而已，非阻塞是不需要cpu切换时间片保存上下文的，节省了大量性能消耗。