深入理解JVM之CAS原子操作（九）

在准备进入concurrentHashMap的源码世界中的时候，发现很多方法是基于CAS原子操作的，之前在看JVM的时候确实看过CAS，但是并没有仔细的去研究，所以决定先一探究竟，经过网上查阅一些资料，对CAS还是有了一些理解。

如果说在只有一个线程的时候，资源不会出现竞争，也不会存在所谓的共享资源的说法，很多问题可以避免，也无需讨论原子性操作的问题。但是当出现多个线程协调运行的时候，很多问题就会出现了，怎么提高多个线程访问共享资源的效率，如何避免多个线程并发读写共享资源时不出现数据混乱，这些问题都是在各个领域很经典的问题。

乐观锁与悲观锁

我们都知道，cpu是时分复用的，也就是把cpu的时间片，分配给不同的thread/process轮流执行，时间片与时间片之间，需要进行cpu切换，也就是会发生进程的切换。切换涉及到清空寄存器，缓存数据。然后重新加载新的thread所需数据。当一个线程被挂起时，加入到阻塞队列，在一定的时间或条件下，在通过notify()，notifyAll()唤醒回来。

在某个资源不可用的时候，就将cpu让出，把当前等待线程切换为阻塞状态。等到资源(比如一个共享数据）可用了，那么就将线程唤醒，让他进入runnable状态等待cpu调度。这就是典型的悲观锁的实现。独占锁是一种悲观锁，synchronized就是一种独占锁，它假设最坏的情况，认为一个线程修改共享数据的时候其他线程也会修改该数据，因此只在确保其它线程不会造成干扰的情况下执行，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。

但是，由于在进程挂起和恢复执行过程中存在着很大的开销。当一个线程正在等待锁时，它不能做任何事，所以悲观锁有很大的缺点。举个例子，如果一个线程需要某个资源，但是这个资源的占用时间很短，当线程第一次抢占这个资源时，可能这个资源被占用，如果此时挂起这个线程，可能立刻就发现资源可用，然后又需要花费很长的时间重新抢占锁，时间代价就会非常的高。

所以就有了乐观锁的概念，他的核心思路就是，每次不加锁而是假设修改数据之前其他线程一定不会修改，如果因为修改过产生冲突就失败就重试，直到成功为止。在上面的例子中，某个线程可以不让出cpu,而是一直while循环，如果失败就重试，直到成功为止。所以，当数据争用不严重时，乐观锁效果更好。比如CAS就是一种乐观锁思想的应用。

synchronized与volatile

在JDK 5之前Java语言是靠synchronized关键字保证同步的，这会导致有锁。既然说到了synchronized关键字，很容易会被拿来比较的就是volatile关键字，但是volatile并不是用来保证同步的，它的一个最大的最突出的特性就是「内存可见性」，意思就是当其他线程更改了一个值之后，这个值对其他线程是立即可见的，也就是说线程能自动读到volatile变量的最新值。但是，它并不能保证操作的原子性，比如计数器里面的典型的自增操作，自增操作中包含读-修改-写，这个操作显然需要具备原子性。如果用volatile变量作为共享字段当做计数器绝大可能是会出错的。所以，volatile与synchronized关键字不能相提并论，使用场景不同，具体volatile的详细可以参见这篇文章。

CAS

概念理解

先上一张图，说明CAS的基本思想：

上图的解释：CPU（此处也可以是线程）去更新一个值，但如果想改的值不再是原来的值，操作就失败，因为很明显，有其它操作先改变了这个值。

CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。执行CAS操作的时候，将内存位置的值与预期原值比较，如果相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。

举个CAS操作的应用场景的一个例子，当一个线程需要修改共享变量的值。完成这个操作，先取出共享变量的值赋给A，然后基于A的基础进行计算，得到新值B，完了需要更新共享变量的值了，这个时候就可以调用CAS方法更新变量值了。

基于CAS的计数器

基于 CAS 的并发算法称为无阻塞算法，因为线程不必再等待阻塞。无论CAS操作成功还是失败，在任何一种情况中，它都在可预知的时间内完成。如果 CAS 失败，调用者不会被挂起而是可以重试CAS操作或采取其他适合的操作。用CAS实现一个计数器代码如下：

public class CasCounter {
    private SimulatedCAS value;//假设SimulatedCAS实现了累加的CAS方法，如compareAndSwap(oldValue, oldValue + 1)
    public int getValue() {
        return value.getValue();
    }
    public int increment() {
        int oldValue = value.getValue();
        while (value.compareAndSwap(oldValue, oldValue + 1) != oldValue)
            oldValue = value.getValue();
        return oldValue + 1;
    }
}

CAS伪代码实现

类似于 CAS 的指令允许算法执行读-修改-写操作，而无需害怕其他线程同时修改变量，因为如果其他线程修改变量，那么 CAS 会检测它（并失败），算法可以对该操作重新计算。下面代码说明了CAS操作的行为（而不是性能特征），但是CAS的价值是它可以在硬件中实现，并且是极轻量级的（在大多数处理器中）：

public class SimulatedCAS {
    private int value;
    public synchronized int getValue() { return value; }
    public synchronized int compareAndSwap(int expectedValue, int newValue) {
         int oldValue = value;
         if (value == expectedValue)
             value = newValue;
         return oldValue;
     }
}

CAS的问题

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

ABA问题。因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
循环时间长开销大。自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
只能保证一个共享变量的原子操作。当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

结束语

JDK 5.0 是开发高性能并发类的巨大进步。通过内部公开新的低级协调原语，和提供一组公共原子变量类，现在用 Java 语言开发无等待、无锁定算法首次变为可行。然后， java.util.concurrent 中的类基于这些低级原子变量工具构建，为它们提供比以前执行相似功能的类更显著的可伸缩性优点。虽然您可能永远不会直接使用原子变量，还是应该为它们的存在而欢呼。（摘自参考3）

参考

Java 多线程：CAS 与 AtomicInteger（乐观锁）
非阻塞同步算法与CAS(Compare and Swap)无锁算法
 Java 理论与实践: 流行的原子

-EOF-