CAS原理及工作中的应用

最近在看Java的并发包，发现追踪下底层大部分都会使用unsafe，对其的理解仅限与使用了CAS算法以及和底层硬件相关等太肤浅。度娘搜索大部分说的让人摸不着头脑，不知所云云。花了一些时间整理如下，以供后期参阅。

参考文档：

http://zl198751.iteye.com/blog/1848575

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

 

一、CAS说明

CAS算法的全称为Compare And Swap，翻译为比较并交换。

该算法的思想是：当要更新的变量（V）的实际值等于变量的预期值（E）时，将V的值设置为新的值（U）；如果V和E的值不同，则说明已经有其他的线程对变量做了更新操作，则当前线程更新失败。

该算法的其作用是对某一个变量进行原子化的更新操作。在开发中的体现就是无锁实现原子操作。

借助CPU底层的指令实现原子操作。由于Java无法直接访问底层操作系统，故CAS通过调用JNI (Java Native Interface为JAVA本地调用) 的代码实现的，允许java调用其他语言。Unsafe，Unsafe是CAS的核心类，它提供了硬件级别的原子操作。（理解CAS和unsafe的区别）。

 

是不是很难理解，举例日常工作中的例子：版本控制工具与之其实非常的相似，如果使用锁来同步，其实就意味着只能同时一个人对该文件进行修改，此时其他人就无法操作文件，如果生活中真正遇到这样的情况我们一定会觉得非常不方便，而现实中我们其实并不是这样，我们大家都可以修改这个文件，只是谁提交的早，那么他就把他的代码成功提交的版本控制服务器上，其实这一步就对应着一个原子操作，而后操作的人往往却因为冲突而导致提交失败，此时他必须重新更新代码进行再次修改，重新提交。

 

二、Java代码示例

最经典的应用就是变量的自增操作。以AtomicInteger为例说明。

 

 

private volatile int value;
 
/** * Gets the current value. 
    *
    *@returnthe current value
    */
public final int get() {
    return value;
}

 

 

在没有锁的机制下需要借助与volatile，保证了线程间的数据可见性，这样在获取变量值时可以直接读取。

 

/** 
* Atomically increments by one the current value. 
* 
* @return the updated value 
*/
public final int incrementAndGet() {
    for (;;) { //通过无限循环来保证最终执行的成功
        int current = get();//获取当前值
        int next = current + 1;//本次之后的值
        if (compareAndSet(current, next)) //使用cas算法操作
            return next;
    }
}
 
 
/** 
* 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 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);
}

 

 

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

 

通过上述例子我们可以进一步理解CAS算法：类似乐观锁机制，总是认为当前线程可以完成更新操作；但是在当前有多个词按成同时CAS一个变量是，最终是只能有一个会操作成功，但是其他失败的线程不会被刮起，而是被告知失败后重新在尝试直至成功。基于此CAS实现了无锁的机制，

在JVM中对一个变量的操作通过三个步骤来完成，读取内存变量值至本地内存、修改本地内存值、会写到内存中。我们知道在多线程环境下上述操作会出现问题，一般是通过加锁处理。但是CAS在底层是通过CPU的1调指令来完成上述三个步骤，故是原子性的，不存在其执行一个步骤时候被中断的可能。

 

 

 

三、底层CPU的指令实现原子操作

那么底层是如何实现原子操作的哪？

下面是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（或）等，被这些指令操作的内存区域就会加锁，导致其他处理器不能同时访问它。

 

 

 

四、java.util.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包的实现示意图如下：

 

 

 

五、与锁相比较

借助CAS实现了区别于synchronouse同步锁的一种乐观锁。其与锁还是有着巨大的区别的，

1、性能方面

当多个线程访问临界区(数据共享的区域)的数据时，如果使用锁来进行并发控制，当某一个线程(T1)抢占到锁之后，那么其他线程再尝试去抢占锁时就会被挂起，当T1释放锁之后，下一个线程(T2)再抢占到锁后并且重新恢复到原来的状态大约需要经过8W个时钟周期。而假设我们业务代码本身并不具备很复杂的操作，执行整个操作可能就花费3-10个时钟周期左右，那么当我们使用无锁操作时，线程T1和线程T2对共享变量进行并发的CAS操作，假设T1成功了，T2最多再执行一次，它执行多次的所消耗的时间远远小于由于线程所挂起到恢复所消耗的时间，它基本不可能运气差到要执行几千次才能完成操作，因此无锁的CAS操作在性能上要比同步锁高很多。

 

2、实际业务

使用同步锁机制锁保证的"先行发生原则(happen before)"过于的粗力度，它虽然可以保证线程T1的操作如果早于线程T2获取锁，那么T1一定在T2之前完成操作；而CAS操作却不能保证这样的顺序的一致性，但是CAS操作保证了关键的修改一步具有先行发生原则。在我们实际的业务场景下，由锁机制保证的这种看似所谓的有序性其实没有太大的意义，因为我们只需保证最终结果的一致性就能满足业务的需要。我们以商品秒杀为例，当多个用户并发访问时，我们其实只需确保的就是其在抢占的那一刻是一个原子操作即可，当商品数目为0时提示操作失败，而无需保证先来的用户一定能够抢到商品。因此，在业务本身的需求上，无锁机制本身就可以满足我们绝大多数的需求，并且在性能上也可以大大的进行提升。

 

六、CAS问题

 

所有的事物都有两面性，CAS虽然很高效的解决了原子操作，但是其本身还是存在缺陷的。

1、循环时间太长

在Java代码示例中我们可以看到用的是无限循环。如果一直不成功怎么办，在自旋CAS长时间不成功，为给CPU带来很大的开销。

 

2、保证单个共享变量是原子操作

通过代码示例也可以看出，CAS只能针对单个变量；如果是多个变量那么就要使用锁了。 从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作（后续会把该部分内容补充上）。

 

3、ABA问题

从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题