CAS原子操做以及其在Java中的应用

CAS（Compare And Swap）意为比较而且交换，CAS它是一个原子操做。CAS操做涉及到三个值：当前内存中的值V，逾期内存中的值E和待更新的值U。若是当前内存中的值V等于预期值E，则将内存中的值更新为U，CAS操做成功。不然不更新CAS操做失败。 CAS在JUC中有普遍的运用，能够说CAS是JUC的基础，没有CAS操做就没有JUC。CAS常常用来实现Java中的乐观锁，相对于Java中的悲观锁synchronized锁，乐观锁不须要挂起和唤醒线程，在高并发状况下，线程频繁挂起和唤醒会影响性能。为了弄清CAS操做，有必要先了解一下乐观锁和悲观锁以及它们之间的区别。

悲观锁和乐观锁

悲观锁认为其余线程的每一次操做都会更新共享变量，所以全部的操做必须互斥，经过悲观锁策略来让全部的操做串行化，全部的线程操做共享变量以前必须获取悲观锁，获取成功则进行操做，获取失败就阻塞当前线程悲观等待。当线程被阻塞住以后CPU将再也不调度线程，在高并发的场景下若是线程激烈竞争某一个锁形成线程频繁挂起和唤醒，无疑将给咱们的应用带来灾难性的打击。悲观锁的流程图以下：

Java中的synchronized锁和ReentrantLock都是悲观的锁，在前面的文章中分析了Java中各类锁的区别，有兴趣的能够前去查看：多线程安全性和Java中的锁。

乐观锁相对悲观锁来讲则是认为其余线程不必定会修改共享变量，所以线程没必要阻塞等待。经过CAS来更新共享变量，若是CAS更新失败则证实其余线程修改了这个共享变量，本身循环重试直到更新成功就能够了。由于CAS操做不会挂起线程所以减小了线程挂起和唤醒的开销，在高并发状况下这个节省是很是可观的。循环重试虽然不会挂起线程可是会消耗CPU，由于线程须要一直循环重试，这也是CAS乐观锁的一个缺点。java.util.concurrent.atomic包下面的Atomic类都是经过CAS乐观锁来保证线程安全性的。CAS乐观锁还有另外一个缺点就是没法解决“ABA”问题。这个后面会进行详细的分析。 基于CAS乐观锁流程图以下所示：

CAS操做以及在Java中的应用

CAS在Java中有不少应用，JUC以及java.util.concurrent.atomic下面的原子类都用到了CAS。

Unsafe提供的CAS操做

Unsafe为Java提供了不少底层功能，其中Java中的CAS功能就是经过这个类来实现的。有兴趣的能够查看我前面专门讲解Unsafe这个类的文章：Java中的Unsafe。

public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
复制代码

Unsafe中提供了Object，int和long类型的CAS操做。其余类型的须要本身实现。CAS它是一个原子操做。要保证线程安全性，除了原子性，还有可见性和有序性。可见性和有序性在Java中均可以经过volatile来实现。

Java中的原子类（java.util.concurrent.atomic）

java.util.concurrent.atomic包中的类经过volatile+CAS重试保证线程安全性。 java.util.concurrent.atomic包下面的原子类能够分为四种类型：

1. 原子标量：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
2. 数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
3. 更新类：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater
4. 复合变量类：AtomicMarkableReference，AtomicStampedReference

原子标量类

咱们主要分析一下AtomicInteger这个类如何保证线程安全性：

AtomicInteger的value是volatile的

public class AtomicInteger extends Number implements java.io.Seriablizable {
    ...
    private volatile int value; // value是volatile的，保证了可见性和有序性
    ...
}
复制代码

AtomicInteger中的value是volatile的，volatile能够保证可见性和有序性。

get操做

public final int get() {
    return value;
}
复制代码

能够看到AtomicInteger的get操做是不加锁的，对于非volatile类型的共享变量，并发操做时，一个读线程未必能立马读取到其余线程对这个共享变量的修改。可是这里的value是volatile的，所以能够立马看到其余线程对value的修改。

incrementAndGet操做

public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
复制代码

incrementAndGet操做会先将value加1，而后返回新的值。这个方法内部会调用Unsafe的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)); // CAS原子更新+循环重试

    return var5;
}
复制代码

能够看到Unsafe中在循环体内先读取内存中的value值，而后CAS更新，若是CAS更新成功则退出，若是更新失败，则循环重试直到更新成功。

在前面的文章中(Java中的Unsafe)咱们分析了Unsafe中提供了三种类型对象的CAS操做：Object，int和long类型。AtomicLong是经过Unsafe提供的long类型的CAS操做实现的，AtomicReference是经过Unsafe提供的Object类型的CAS操做实现的，而AtomicBoolean中的value也是一个int类型，AtomicBoolean对int作了一个转换：

public AtomicBoolean(boolean initialValue) {
    value = initialValue ? 1 : 0;
}
复制代码

1表示true，0表示false。所以AtomicBoolean也是经过Unsafe提供的int类型的CAS操做来实现的。

数组类

Unsafe提供了数组相关的两个主要功能：

public native int arrayBaseOffset(Class<?> var1);

public native int arrayIndexScale(Class<?> var1);
复制代码

AtomicIntegerArray主要就是使用这两个方法来实现数组CAS操做。AtomicIntegerArray中主要的一些功能以下：

private static final Unsafe unsafe = Unsafe.getUnsafe();  
private static final int base = unsafe.arrayBaseOffset(int[].class);  // 获取数组中第一个元素实际地址相对整个数组对象的地址的偏移量
private static final int scale = unsafe.arrayIndexScale(int[].class); // 获取数组中第一个元素所占用的内存空间
private final int[] array;  
public final int get(int i) {  
    return unsafe.getIntVolatile(array, rawIndex(i));  
}  
public final void set(int i, int newValue) {  
    unsafe.putIntVolatile(array, rawIndex(i), newValue);  
}
复制代码

AtomicLongArray和AtomicReferenceArray实现原理和AtomicIntegerArray相似。

更新类

AtomicLongFieldUpdater用来更新一个对象的 volatile long 类型的属性，这个属性是实例的属性而不是类的属性，也就是说只能用来更新一个对象的实例的非static属性。 与AtomicLongFieldUpdater相似AtomicIntegerFieldUpdater用来更新一个对象的 volatile int 类型的属性。

AtomicLongFieldUpdater和AtomicIntegerFieldUpdater都是用来更新一个对象的原生属性(int long)，而AtomicReferenceFieldUpdater用来更新一个对象的包装类型属性。

复合变量类

基于CAS乐观锁没法解决“ABA”问题。解决“ABA”问题的主要思路就是给value打戳，AtomicStampedReference就是经过对值加一个戳(stamp)来解决“ABA”问题的。

public class AtomicStampedReference<V> {

    private static class Pair<T> {
        final T reference; // 值
        final int stamp; // 值的戳
        private Pair(T reference, int stamp) {
            this.reference = reference;
            this.stamp = stamp;
        }
        static <T> Pair<T> of(T reference, int stamp) {
            return new Pair<T>(reference, stamp);
        }
    }

    private volatile Pair<V> pair; // volatile保证可见性和有序性
    ...
    public boolean compareAndSet(V   expectedReference,
                                 V   newReference,
                                 int expectedStamp,
                                 int newStamp) {
        Pair<V> current = pair;
        return
            expectedReference == current.reference &&
            expectedStamp == current.stamp &&
            ((newReference == current.reference &&
              newStamp == current.stamp) ||
             casPair(current, Pair.of(newReference, newStamp)));
    }
    ...
    private boolean casPair(Pair<V> cmp, Pair<V> val) {
        return UNSAFE.compareAndSwapObject(this, pairOffset, cmp, val); // 经过Unsafe的compareAndSwapObject来更新
    }
    ...
}
复制代码

总结

1. java.util.concurrent.atomic经过基于CAS的乐观锁保证线程安全性。在多读少写的场景下，较synchronized锁和ReentrantLock的悲观锁性能会更好。
2. JUC中大量运行了Unsafe的CAS操做，Unsafe的CAS是JUC的基础。
3. 基于CAS的乐观锁没法解决“ABA”问题，AtomicStampedReference经过加戳来解决“ABA”问题。
4. 基于CAS+循环的乐观锁会大量消耗CPU。