转：JAVA CAS原理深度分析

看了一堆文章，终于把Java CAS的原理深刻分析清楚了。

感谢GOOGLE强大的搜索，借此挖苦下百度，依靠百度什么都学习不到！

 

参考文档：

http://www.blogjava.net/xylz/archive/2010/07/04/325206.html

http://blog.hesey.net/2011/09/resolve-aba-by-atomicstampedreference.html

http://www.searchsoa.com.cn/showcontent_69238.htm

http://ifeve.com/atomic-operation/

http://www.infoq.com/cn/articles/java-memory-model-5

 

java.util.concurrent包彻底创建在CAS之上的，没有CAS就不会有此包。可见CAS的重要性。

 

CAS

CAS:Compare and Swap, 翻译成比较并交换。 

java.util.concurrent包中借助CAS实现了区别于synchronouse同步锁的一种乐观锁。

 

本文先从CAS的应用提及，再深刻原理解析。

 

CAS应用

CAS有3个操做数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改成B，不然什么都不作。

 

非阻塞算法 （nonblocking algorithms）

一个线程的失败或者挂起不该该影响其余线程的失败或挂起的算法。

现代的CPU提供了特殊的指令，能够自动更新共享数据，并且可以检测到其余线程的干扰，而 compareAndSet() 就用这些代替了锁定。

拿出AtomicInteger来研究在没有锁的状况下是如何作到数据正确性的。

private volatile int value;

首先毫无觉得，在没有锁的机制下可能须要借助volatile原语，保证线程间的数据是可见的（共享的）。

这样才获取变量的值的时候才能直接读取。

public final int get() {
        return value;
    }

而后来看看++i是怎么作到的。

public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}

在这里采用了CAS操做，每次从内存中读取数据而后将此数据和+1后的结果进行CAS操做，若是成功就返回结果，不然重试直到成功为止。

而compareAndSet利用JNI来完成CPU指令的操做。

public final boolean compareAndSet(int expect, int update) {   
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

总体的过程就是这样子的，利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法。其它原子操做都是利用相似的特性完成的。

 

其中

unsafe.compareAndSwapInt(this, valueOffset, expect, update);

相似：

if (this == expect) {

  this = update

 return true;

} else {

return false;

}

 

那么问题就来了，成功过程当中须要2个步骤：比较this == expect，替换this = update，compareAndSwapInt如何这两个步骤的原子性呢？ 参考CAS的原理。

 

CAS原理

 CAS经过调用JNI的代码实现的。JNI:Java Native Interface为JAVA本地调用，容许java调用其余语言。

而compareAndSwapInt就是借助C来调用CPU底层指令实现的。

下面从分析比较经常使用的CPU（intel x86）来解释CAS的实现原理。

 下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码：

public final native boolean compareAndSwapInt(Object o, long offset,
                                              int expected,
                                              int x);

 

能够看到这是个本地方法调用。这个本地方法在openjdk中依次调用的c++代码为：unsafe.cpp，atomic.cpp和atomicwindowsx86.inline.hpp。这个本地方法的最终实如今openjdk的以下位置：openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp（对应于windows操做系统，X86处理器）。下面是对应于intel x86处理器的源代码的片断：

 

// Adding a lock prefix to an instruction on MP machine
// VC++ doesn't like the lock prefix to be on a single line
// so we can't insert a label after the lock prefix.
// By emitting a lock prefix, we can define a label after it.
#define LOCK_IF_MP(mp) __asm cmp mp, 0  \
                       __asm je L0      \
                       __asm _emit 0xF0 \
                       __asm L0:

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  // alternative for InterlockedCompareExchange
  int mp = os::is_MP();
  __asm {
    mov edx, dest
    mov ecx, exchange_value
    mov eax, compare_value
    LOCK_IF_MP(mp)
    cmpxchg dword ptr [edx], ecx
  }
}

如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。若是程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（lock cmpxchg）。反之，若是程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不须要lock前缀提供的内存屏障效果）。

 

 intel的手册对lock前缀的说明以下：

1. 确保对内存的读-改-写操做原子执行。在Pentium及Pentium以前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其余处理器暂时没法经过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上作了一个颇有意义的优化：若是要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），而且该内存区域被彻底包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。因为在指令执行期间该缓存行会一直被锁定，其它处理器没法读/写该指令要访问的内存区域，所以能保证指令执行的原子性。这个操做过程叫作缓存锁定（cache locking），缓存锁定将大大下降lock前缀指令的执行开销，可是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
2. 禁止该指令与以前和以后的读和写指令重排序。
3. 把写缓冲区中的全部数据刷新到内存中。

备注知识：

关于CPU的锁有以下3种：

　　3.1 处理器自动保证基本内存操做的原子性

　　首先处理器会自动保证基本的内存操做的原子性。处理器保证从系统内存当中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其余处理器不能访问这个字节的内存地址。奔腾6和最新的处理器能自动保证单处理器对同一个缓存行里进行16/32/64位的操做是原子的，可是复杂的内存操做处理器不能自动保证其原子性，好比跨总线宽度，跨多个缓存行，跨页表的访问。可是处理器提供总线锁定和缓存锁定两个机制来保证复杂内存操做的原子性。 

　　3.2 使用总线锁保证原子性

　　第一个机制是经过总线锁保证原子性。若是多个处理器同时对共享变量进行读改写（i++就是经典的读改写操做）操做，那么共享变量就会被多个处理器同时进行操做，这样读改写操做就不是原子的，操做完以后共享变量的值会和指望的不一致，举个例子：若是i=1,咱们进行两次i++操做，咱们指望的结果是3，可是有可能结果是2。以下图

 

 

　　缘由是有可能多个处理器同时从各自的缓存中读取变量i，分别进行加一操做，而后分别写入系统内存当中。那么想要保证读改写共享变量的操做是原子的，就必须保证CPU1读改写共享变量的时候，CPU2不能操做缓存了该共享变量内存地址的缓存。

　　处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个LOCK＃信号，当一个处理器在总线上输出此信号时，其余处理器的请求将被阻塞住,那么该处理器能够独占使用共享内存。

　　3.3 使用缓存锁保证原子性

　　第二个机制是经过缓存锁定保证原子性。在同一时刻咱们只需保证对某个内存地址的操做是原子性便可，但总线锁定把CPU和内存之间通讯锁住了，这使得锁按期间，其余处理器不能操做其余内存地址的数据，因此总线锁定的开销比较大，最近的处理器在某些场合下使用缓存锁定代替总线锁定来进行优化。

　　频繁使用的内存会缓存在处理器的L1，L2和L3高速缓存里，那么原子操做就能够直接在处理器内部缓存中进行，并不须要声明总线锁，在奔腾6和最近的处理器中可使用“缓存锁定”的方式来实现复杂的原子性。所谓“缓存锁定”就是若是缓存在处理器缓存行中内存区域在LOCK操做期间被锁定，当它执行锁操做回写内存时，处理器不在总线上声言LOCK＃信号，而是修改内部的内存地址，并容许它的缓存一致性机制来保证操做的原子性，由于缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据，当其余处理器回写已被锁定的缓存行的数据时会起缓存行无效，在例1中，当CPU1修改缓存行中的i时使用缓存锁定，那么CPU2就不能同时缓存了i的缓存行。

　　可是有两种状况下处理器不会使用缓存锁定。第一种状况是：当操做的数据不能被缓存在处理器内部，或操做的数据跨多个缓存行（cache line），则处理器会调用总线锁定。第二种状况是：有些处理器不支持缓存锁定。对于Inter486和奔腾处理器,就算锁定的内存区域在处理器的缓存行中也会调用总线锁定。

　　以上两个机制咱们能够经过Inter处理器提供了不少LOCK前缀的指令来实现。好比位测试和修改指令BTS，BTR，BTC，交换指令XADD，CMPXCHG和其余一些操做数和逻辑指令，好比ADD（加），OR（或）等，被这些指令操做的内存区域就会加锁，致使其余处理器不能同时访问它。

 

CAS缺点

 CAS虽然很高效的解决原子操做，可是CAS仍然存在三大问题。ABA问题，循环时间长开销大和只能保证一个共享变量的原子操做

1.  ABA问题。由于CAS须要在操做值的时候检查下值有没有发生变化，若是没有发生变化则更新，可是若是一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，可是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。

从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法做用是首先检查当前引用是否等于预期引用，而且当前标志是否等于预期标志，若是所有相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

关于ABA问题参考文档: http://blog.hesey.net/2011/09/resolve-aba-by-atomicstampedreference.html

2. 循环时间长开销大。自旋CAS若是长时间不成功，会给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操做。

 

 

concurrent包的实现

因为java的CAS同时具备 volatile 读和volatile写的内存语义，所以Java线程之间的通讯如今有了下面四种方式：

1. A线程写volatile变量，随后B线程读这个volatile变量。
2. A线程写volatile变量，随后B线程用CAS更新这个volatile变量。
3. A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。
4. A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操做，这是在多处理器中实现同步的关键（从本质上来讲，可以支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，所以任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操做的原子指令）。同时，volatile变量的读/写和CAS能够实现线程之间的通讯。把这些特性整合在一块儿，就造成了整个concurrent包得以实现的基石。若是咱们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：

1. 首先，声明共享变量为volatile；
2. 而后，使用CAS的原子条件更新来实现线程之间的同步；
3. 同时，配合以volatile的读/写和CAS所具备的volatile读和写的内存语义来实现线程之间的通讯。

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从总体来看，concurrent包的实现示意图以下：