暴力突破 Java 并发 - CAS 解析

一、CAS 概念

---

在 JDK 5 之前 Java 语言是靠 synchronized 关键字保证同步的，这会导致有锁，锁机制存在以下问题：

1. 在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
2. 一个线程持有锁会导致其它所有需要此锁的线程挂起。
3. 如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

volatile 是不错的机制，但是 volatile 不能保证原子性，因此对于同步最终还是要回到锁机制上来。独占锁是一种悲观锁，synchronized 就是一种独占锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。而另一个更加有效的锁就是乐观锁。

所谓乐观锁即总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和 CAS 算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于 write_condition 机制，其实都是提供的乐观锁。在 Java 中 java.util.concurrent.atomic 包下面的原子变量类就是使用了乐观锁的一种实现方式 CAS 实现的。

 

二、使用

---

在 JDK1.5+ 的版本中，Doug Lea 和他的团队为我们提供了一套用于保证线程安全的原子操作。我们都知道在多线程环境下，对于更新对象中的某个属性、更新基本类型数据、更新数组（集合）都可能产生脏数据问题。为了避免多线程环境下的脏数据问题，JDK1.5的版本中为我们提供了 java.util.concurrent.atomic 原子操作包。所谓“原子”操作，是指一组不可分割的操作：操作者对目标对象进行操作时，要么完成所有操作后其他操作者才能操作；要么这个操作者不能进行任何操作；

java.util.concurrent.atomic 原子操作包为我们提供了四类原子操作：原子更新基本类型，原子更新数组，原子更新引用和原子更新字段。灵活使用它们完全可以我们在日常工作中遇到的多线程数据脏读问题。

基本的使用过程如下：

import java.util.concurrent.atomic.AtomicInteger;
 
public class TestAtomic {
    public static void main(String[] args) throws Exception {
        // 实例化了一个AtomicInteger类的对象atomic并定义初始值为1
        AtomicInteger atomic = new AtomicInteger(1);
        // 进行atomic的原子化操作：增加1并且获取这个增加后的新值
        atomic.incrementAndGet();
    }
}

 

三、CAS 原理

---

CAS 的思想很简单，三个参数：当前内存值 V、旧的预期值 A、即将更新的值 B，当且仅当预期值 A 和内存值 V 相同时，将内存值修改为 B 并返回 true，否则什么都不做，并返回 false。我们拿 AtomicInteger 类来分析，先来看看 AtomicInteger 静态代码块片段：

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

  // setup to use Unsafe.compareAndSwapInt for updates
  private static final Unsafe unsafe = Unsafe.getUnsafe();
  private static final long valueOffset;

  static {
    try {
      valueOffset = unsafe.objectFieldOffset
        (AtomicInteger.class.getDeclaredField("value"));
    } catch (Exception ex) { throw new Error(ex); }
  }

  private volatile int value;
  
  // 省略部分代码
}

这里用到了可以提供硬件级别的原子操作的 sun.misc.Unsafe 类，它可以获取某个属性在内存中的位置，也可以修改对象的字段值，只不过该类对一般开发而言，很少会用到，其底层是用 C/C++ 实现的，所以它的方式都是被 native 关键字修饰过的。可以看得出 AtomicInteger 类存储的值是在 value 字段中，并且获取了 Unsafe 实例，在静态代码块中，还获取了 value 字段在内存中的偏移量 valueOffset。接下来我们看个例子：

public class AddIntTest {
  public AtomicInteger i;
  public void add() {
    i.getAndIncrement();
  }
}

如上，getAndIncrement() 方法底层利用 CAS 技术保证了并发安全。

public final int getAndIncrement() {
  return unsafe.getAndAddInt(this, valueOffset, 1);
}

getAndAddInt 方法：

public final int getAndAddInt(Object var1, long var2, int var4) {
  int var5;
  do {
    var5 = this.getIntVolatile(var1, var2);
  } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));// 自旋
  return var5;
}

var5 通过 this.getIntVolatile(var1, var2) 方法获取，是个 native 方法，其目的是获取 var1 在 var2 偏移量的值，其中 var1 就是 AtomicInteger，var2 是 valueOffset 值。

那么 CAS 核心重点来了，这里我们见到compareAndSwapInt这个函数，它也是CAS缩写的由来。那么仔细分析下这个函数做了什么呢？compareAndSwapInt 就是实现 CAS 的核心方法，其原理是如果 var1 中的 value 值和 var5 相等，就证明没有其他线程改变过这个变量，那么就把 value 值更新为 var5 + var4，其中 var4 是更新的增量值；反之如果没有更新，那么 CAS 就一直采用自旋的方式继续进行操作（其实就是个 while 循环），乍一看这也是两个步骤了啊，其实在JNI里是借助于一个CPU指令完成的。所以还是原子操作。

CAS 的原子性实际上是 CPU 实现的，其实在这一点上还是有排他锁的，只是比起用 synchronized 这里的排他时间要短的多，所以在多线程情况下性能会比较好。

举例分析：

1. 设定 AtomicInteger 的 value 原始值为 A，从 Java 内存模型得知，线程 1 和线程 2 各自持有一份 value 的副本，值都是 A。
2. 线程 1 通过getIntVolatile(var1, var2)拿到 value 值 A，这时线程 1 被挂起。
3. 线程 2 也通过getIntVolatile(var1, var2)方法获取到 value 值 A，并执行compareAndSwapInt方法比较内存值也为 A，成功修改内存值为 B。
4. 这时线程 1 恢复执行compareAndSwapInt方法比较，发现自己手里的值 A 和内存的值 B 不一致，说明该值已经被其它线程提前修改过了。
5. 线程 1 重新执行getIntVolatile(var1, var2)再次获取 value 值，因为变量 value 被 volatile 修饰，所以其它线程对它的修改，线程 A 总是能够看到，线程A继续执行compareAndSwapInt进行比较替换，直到成功。

compareAndSwapInt 方法是一个本地方法：

public final native boolean compareAndSwapInt(Object paramObject, long paramLong, int paramInt1, int paramInt2);

Java 并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的。Java 代码需通过 JNI 才能调用，位于 unsafe.cpp，查看源码：

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
  UnsafeWrapper("Unsafe_CompareAndSwapInt");
  oop p = JNIHandles::resolve(obj);
  jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
  return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END

大概知道如下意思：

1. 先想办法拿到变量 value 在内存中的地址。
2. 通过Atomic::cmpxchg实现比较替换，其中参数 x 是即将更新的值，参数 e 是原内存的值。

 

四、CAS的缺点

---

CAS虽然很高效的解决了原子操作问题，但是 CAS 仍然存在三大问题。

1、循环时间长开销很大

我们可以看到 getAndAddInt 方法执行时，如果CAS失败，会一直进行尝试。如果 CAS 长时间一直不成功，可能会给 CPU 带来很大的开销。

2、只能保证一个共享变量的原子操作

当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁来保证原子性。

3、ABA问题

如果内存地址 V 初次读取的值是 A，并且在准备赋值的时候检查到它的值仍然为 A，那我们就能说它的值没有被其他线程改变过了吗？如果在这段期间它的值曾经被改成了 B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。这个漏洞称为 CAS 操作的“ABA”问题。Java 并发包为了解决这个问题，提供了一个带有标记的原子引用类“AtomicStampedReference”，它可以通过控制变量值的版本来保证 CAS 的正确性。因此，在使用 CAS 前要考虑清楚“ABA”问题是否会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效。