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。