Java併發程式設計-CAS

　　，學習了併發程式設計中的volatile，最後取了網上流傳很廣的一張圖來結尾，從圖中可以看出除了volatile變數的讀寫，還有一個叫做CAS的東西，所以這篇文章再來學習CAS。

1、  併發程式設計三要素-原子性、可見性、有序性

　　在討論CAS前，我想先討論一下併發程式設計的三要素，這個應該可以幫助理解CAS的作用等。其實上一篇提到的Java記憶體模型就是圍繞著在併發過程中如何處理原子性、可見性和有序性這3個特徵來建立的，所以我理解Java程式設計實現如果滿足了這3個特性，就是執行緒安全的，可以支援併發訪問。

原子性：指的是一個操作不能再繼續拆分，要麼一次操作完成，要麼就是不執行。在Java中，為了保證原子性，提供了兩個高階的位元組碼指令（monitorenter和monitorexit），這個就是關鍵字synchronized，可以看。我理解其實還有一種操作也是可以滿足原子性的，就是CAS。

可見性：指的是一個變數在被一個執行緒更改後，其他的執行緒能立即看到最新的值。

有序性：指的是程式的執行按照程式碼的先後順序執行。對於可見性和有序性，Java提供了關鍵字volatile，volatile禁止指令重排，保證了有序性，同時volatile可以保證變數的讀寫及時從快取中重新整理到主存，也就保證了可見性，可以看。除此以外，synchronized是可見性和有序性另外一種實現，同步方法和同步程式碼塊保證一個變數在同一時間只能有一個執行緒訪問，這就是一種先後順序，而對於可見性保證，只能有一個執行緒操作變數，那麼其他執行緒只能在前一個執行緒操作完成後才可以看到變數最新的值。

我們可以發現synchronized一次性滿足了3個特性，那麼我們是不是可以大膽的認為CAS+volatile組合在一起也可以滿足3個特性。         

2、  CAS介紹

　　CAS全稱compare-and-swap，是電腦科學中一種實現多執行緒原子操作的指令，它比較記憶體中當前存在的值和外部給定的期望值，只有兩者相等時，才將這個記憶體值修改為新的給定值。CAS操作包含三個運算元，需要讀寫的記憶體位置（V）、擬比較的預期原值（A）和擬寫入的新值（B），如果V的值和A的值匹配，則將V的值更新為B，否則不做任何操作。多執行緒嘗試使用CAS更新同一變數時，只有一個執行緒可以操作成功，其他的執行緒都會失敗，失敗的執行緒不會被掛起，只是在此次競爭中被告知失敗，下次可以繼續嘗試CAS操作的。

3、  CAS背後實現

　　JUC下的atomic類都是透過CAS來實現的，下面就以AtomicInteger為例來闡述CAS的實現。直接看方法compareAndSet，呼叫了unsafe類的compareAndSwapInt方法：

public final boolean compareAndSet(int expect, int update) {        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

　　其中四個引數分別表示物件、物件的地址（定位到V）、預期值（A）、修改值（B）。

　　再看unsafe類的方法，這是一個native方法，所以只能繼續放看openJDK的程式碼。

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

　　在unsafe.cpp找到方法CompareAndSwapInt，可以依次看到變數obj、offset、e和x，其中addr就是當前記憶體位置指標，最終再呼叫Atomic類的cmpxchg方法。

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

　　找到類atomic.hpp，從變數命名上基本可以見名知義。

static jint     cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value);

　　和volatile型別，CAS也是依賴不同的CPU會有不同的實現，在src/os_cpu目錄下可以看到不同的實現，以atomic_linux_x86.inline.hpp為例，是這麼實現的：

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");  return exchange_value;
}

　　底層是透過指令cmpxchgl來實現，如果程式是多核環境下，還會先在cmpxchgl前生成lock指令字首，反之如果是在單核環境下就不需要生成lock指令字首。為什麼多核要生成lock指令字首？因為CAS是一個原子操作，原子操作隱射到計算機的實現，多核CPU的時候，如果這個操作給到了多個CPU，就破壞了原子性，所以多核環境肯定得先加一個lock指令，不管這個它是以匯流排鎖還是以快取鎖來實現的，單核就不存在這樣的問題了。

4、  CAS存在的問題

4.1  ABA問題

　　因為CAS需要在操作值的時候，檢查值有沒有發生變化，如果沒有發生變化則更新，但是如果一個值原來是A，變成了B，又變成了A，那麼使用CAS進行檢查時會發現它的值沒有發生變化，但是實際上卻變化了。ABA問題的解決思路就是使用版本號。在變數前面追加上版本號，每次變數更新的時候把版本號加1，那麼ABA就會變成1A2B3A。

　　關於ABA問題的舉例，參考連結裡面有篇文章其實說的很清楚了，不過我認為他這個例子好像描述的有點問題，應該是執行緒1希望A替換為B，執行操作CAS（A,B），此時執行緒2做了個操作，將AB變成了AC，A的版本已經發生了變化，再執行執行緒1時會認為A還是那個A，連結串列變成BC，如果有B.next=null，C這個節點就丟失了。

　　從Java 1.5開始，JDK的Atomic包裡提供了一個類AtomicStampedReference來解決ABA問題。這個類的compareAndSet方法的作用是首先檢查當前引用是否等於預期引用，並且檢查當前標誌是否等於預期標誌，如果全部相等，則以原子方式將該引用和該標誌的值設定為給定的更新值。

4.2  迴圈時間長開銷大

　　一般CAS操作都是在不停的自旋，這個操作本身就有可能會失敗的，如果一直不停的失敗，則會給CPU帶來非常大的開銷。

4.3  只能保證一個共享變數的原子操作

　　看了CAS的實現就知道這個只能針對一個共享變數，如果是多個共享變數就只能使用synchronized。除此之外，可以考慮使用AtomicReference來包裝多個變數，透過這種方式來處理多個共享變數的情況。

參考資料：

https://github.com/lingjiango/ConcurrentProgramPractice

http://cmsblogs.com/?p=2235