上一篇文章，學習了併發編程中的volatile，最後取了網上流傳很廣的一張圖來結尾，從圖中可以看出除了volatile變數的讀寫，還有一個叫做CAS的東西，所以這篇文章再來學習CAS。 1、 併發編程三要素-原子性、可見性、有序性 在討論CAS前，我想先討論一下併發編程的三要素，這個應該可以幫助理解 ...
上一篇文章，學習了併發編程中的volatile，最後取了網上流傳很廣的一張圖來結尾，從圖中可以看出除了volatile變數的讀寫，還有一個叫做CAS的東西，所以這篇文章再來學習CAS。
1、 併發編程三要素-原子性、可見性、有序性
在討論CAS前，我想先討論一下併發編程的三要素，這個應該可以幫助理解CAS的作用等。其實上一篇提到的Java記憶體模型就是圍繞著在併發過程中如何處理原子性、可見性和有序性這3個特征來建立的，所以我理解Java編程實現如果滿足了這3個特性，就是線程安全的，可以支持併發訪問。
原子性：指的是一個操作不能再繼續拆分，要麼一次操作完成，要麼就是不執行。在Java中，為了保證原子性，提供了兩個高級的位元組碼指令（monitorenter和monitorexit），這個就是關鍵字synchronized，可以看Java併發編程-synchronized。我理解其實還有一種操作也是可以滿足原子性的，就是CAS。
可見性：指的是一個變數在被一個線程更改後，其他的線程能立即看到最新的值。
有序性：指的是程式的執行按照代碼的先後順序執行。對於可見性和有序性，Java提供了關鍵字volatile，volatile禁止指令重排，保證了有序性，同時volatile可以保證變數的讀寫及時從緩存中刷新到主存，也就保證了可見性，可以看Java併發編程-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，那麼A→B→A就會變成1A→2B→3A。
關於ABA問題的舉例，參考鏈接裡面有篇文章其實說的很清楚了，不過我認為他這個例子好像描述的有點問題，應該是線程1希望A替換為B，執行操作CAS（A,B），此時線程2做了個操作，將A→B變成了A→C，A的版本已經發生了變化，再執行線程1時會認為A還是那個A，鏈表變成B→C，如果有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
https://en.wikipedia.org/wiki/Compare-and-swap
