CAS的英文爲Compare and Swap 翻譯爲比較並交換。
CAS加volatile關鍵字是實現併發包的基石。沒有CAS就不會有併發包，synchronized是一種獨佔鎖、悲觀鎖，java.util.concurrent中藉助了CAS指令實現了一種區別於synchronized的一種樂觀鎖。
什麼是樂觀鎖與悲觀鎖？
悲觀鎖：總是假設最壞的情況，每次去拿數據的時候都認爲別人會修改，所以每次在拿數據的時候都會上鎖，這樣當第二個線程想拿這個數據的時候，第二個線程會一直堵塞，直到第一個釋放鎖，他拿到鎖後纔可以訪問。傳統的數據庫裏面就用到了這種鎖機制，例如：行鎖，表鎖，讀鎖，寫鎖，都是在操作前先上鎖。java中的synchronized的實現也是一種悲觀鎖。
樂觀鎖：樂觀鎖概念爲，每次拿數據的時候都認爲別的線程不會修改這個數據，所以不會上鎖，但是在更新的時候會判斷一下在此期間別的線程有沒有修改過數據，樂觀鎖適用於讀操作多的場景，這樣可以提高程序的吞吐量。在Java中java.util.concurrent.atomic包下面的原子變量就是使用了樂觀鎖的一種實現方式CAS實現。
樂觀鎖的實現方式-CAS（Compare and Swap）：
jdk1.5之前鎖存在的問題：
java在1.5之前都是靠synchronized關鍵字保證同步，synchronized保證了無論哪個線程持有共享變量的鎖，都會採用獨佔的方式來訪問這些變量。這種情況下：
1.在多線程競爭下，加鎖、釋放鎖會導致較多的上下文切換和調度延時，引起性能問題
2.如果一個線程持有鎖，其他的線程就都會掛起，等待持有鎖的線程釋放鎖。
3.如果一個優先級高的線程等待一個優先級低的線程釋放鎖，會導致優先級倒置，引起性能風險。
對比於悲觀鎖的這些問題，另一個更加有效的鎖就是樂觀鎖。 樂觀鎖就是：每次不加鎖而是假設沒有併發衝突去操作同一變量，如果有併發衝突導致失敗，則重試直至成功。
樂觀鎖：
樂觀鎖（ Optimistic Locking ）在上文已經說過了，其實就是一種思想。相對悲觀鎖而言，樂觀鎖假設認爲數據一般情況下不會產生併發衝突，所以在數據進行提交更新的時候，纔會正式對數據是否產生併發衝突進行檢測，如果發現併發衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做。
上面提到的樂觀鎖的概念中其實已經闡述了它的具體實現細節：主要就是兩個步驟：衝突檢測和數據更新。其實現方式有一種比較典型的就是 Compare and Swap ( CAS )。
樂觀鎖的一種典型實現機制（CAS）:
樂觀鎖主要就是兩個步驟：衝突檢測和數據更新。當多個線程嘗試使用CAS同時更新同一個變量時，只有一個線程可以更新變量的值，其他的線程都會失敗，失敗的線程並不會掛起，而是告知這次競爭中失敗了，並可以再次嘗試。
CAS操作包括三個操作數：需要讀寫的內存位置(V)、預期原值(A)、新值(B)。如果內存位置與預期原值的A相匹配，那麼將內存位置的值更新爲新值B。如果內存位置與預期原值的值不匹配，那麼處理器不會做任何操作。無論哪種情況，它都會在 CAS 指令之前返回該位置的值。（在 CAS 的一些特殊情況下將僅返回 CAS 是否成功，而不提取當前值。）CAS其實就是一個：我認爲位置 V 應該包含值 A；如果包含該值，則將 B 放到這個位置；否則，不要更改該位置，只告訴我這個位置現在的值即可。這其實和樂觀鎖的衝突檢測+數據更新的原理是一樣的。
樂觀鎖是一種思想，CAS只是這種思想的一種實現方式。
JAVA對CAS的支持：
在JDK1.5新增的java.util.concurrent(JUC java併發工具包)就是建立在CAS之上的。相比於synchronized這種堵塞算法，CAS是非堵塞算法的一種常見實現。所以JUC在性能上有了很大的提升。
下面通過看下併發包中的原子操作類AtomicInteger來看下，如何在不使用鎖的情況下保證線程安全，主要看下getAndIncrement方法，相當於i++的操作：
public class AtomicInteger extends Number implements java.io.Serializable {
private volatile int value;
public final int get() {
return value;
}
public final int getAndIncrement() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return current;
}
}
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
}
首先value使用了volatile修飾，這就保證了他的可見性與有序性，getAndIncrement採用CAS操作，每次從內存中讀取數據然後將數據進行+1操作，然後對原數據，+1後的結果進行CAS操作，成功的話返回結果，否則重試直到成功爲止。其中調用了compareAndSet利用JNI（java navite Interface navite修飾的方法，都是java調用其他語言的方法來實現的）來完成CPU的操作。其中compareAndSwapInt類似如下邏輯：
if (this == expect) {
this = update
return true;
} else {
return false;
}
this == expect和this = update，這兩個步驟是如何保證原子性的呢？
JAVA實現CAS的原理：
compareAndSwapInt是藉助C來調用CPU底層指令實現的。下面從分析比較常用的CPU（intel x86）來解釋CAS的實現原理。下面是sun.misc.Unsafe類的compareAndSwapInt()方法的源代碼：
public final native boolean compareAndSwapInt(Object o, long offset,
int expected, int x);
再看下在JDK中依次調用的C++代碼爲：
#define LOCK_IF_MP(mp) __asm cmp mp, 0 \
__asm je L0 \
__asm _emit 0xF0 \
__asm L0:
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
// alternative for InterlockedCompareExchange
int mp = os::is_MP();
__asm {
mov edx, dest
mov ecx, exchange_value
mov eax, compare_value
LOCK_IF_MP(mp)
cmpxchg dword ptr [edx], ecx
}
}
如上面源代碼所示，程序會根據當前處理器的類型來決定是否爲cmpxchg指令添加lock前綴。如果程序是在多處理器上運行，就爲cmpxchg指令加上lock前綴（lock cmpxchg）。反之，如果程序是在單處理器上運行，就省略lock前綴（單處理器自身會維護單處理器內的順序一致性，不需要lock前綴提供的內存屏障效果）。
CAS的缺陷：
1.ABA問題
比如說一個線程one從內存位置V中取出A，這時候另一個線程two也從內存中取出A，並且two進行了一些操作變成了B，然後two又將V位置的數據變成A，這時候線程one進行CAS操作發現內存中仍然是A，然後one操作成功。儘管線程one的CAS操作成功，但可能存在潛藏的問題。如下所示：
現有一個用單向鏈表實現的堆棧，棧頂爲A，這時線程T1已經知道A.next爲B，然後希望用CAS將棧頂替換爲B： head.compareAndSet(A,B); 在T1執行上面這條指令之前，線程T2介入，將A、B出棧，再pushD、C、A，此時堆棧結構如下圖，而對象B此時處於遊離狀態：
此時輪到線程T1執行CAS操作，檢測發現棧頂仍爲A，所以CAS成功，棧頂變爲B，但實際上B.next爲null，所以此時的情況變爲：
其中堆棧中只有B一個元素，C和D組成的鏈表不再存在於堆棧中，平白無故就把C、D丟掉了。
解決方法（AtomicStampedReference 帶有時間戳的對象引用）：
從Java1.5開始JDK的atomic包裏提供了一個類AtomicStampedReference來解決ABA問題。這個類的compareAndSet方法作用是首先檢查當前引用是否等於預期引用，並且當前標誌是否等於預期標誌，如果全部相等，則以原子方式將該引用和該標誌的值設置爲給定的更新值。
public boolean compareAndSet(
V expectedReference,//預期引用
V newReference,//更新後的引用
int expectedStamp, //預期標誌
int newStamp //更新後的標誌
)
2.循環時間長開銷大
自旋CAS（不成功，就一直循環執行，直到成功）如果長時間不成功，會給CPU帶來非常大的執行開銷。如果JVM能支持處理器提供的pause指令那麼效率會有一定的提升，pause指令有兩個作用，第一它可以延遲流水線執行指令（de-pipeline）,使CPU不會消耗過多的執行資源，延遲的時間取決於具體實現的版本，在一些處理器上延遲時間是零。第二它可以避免在退出循環的時候因內存順序衝突（memory order violation）而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執行效率。
3.只能保證一個共享變量的原子操作
當對一個共享變量執行操作時，我們可以使用循環CAS的方式來保證原子操作，但是對多個共享變量操作時，循環CAS就無法保證操作的原子性，這個時候就可以用鎖，或者有一個取巧的辦法，就是把多個共享變量合併成一個共享變量來操作。比如有兩個共享變量i＝2,j=a，合併一下ij=2a，然後用CAS來操作ij。從Java1.5開始JDK提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象裏來進行CAS操作。
CAS與Synchronized的使用情景：
1、對於資源競爭較少（線程衝突較輕）的情況，使用synchronized同步鎖進行線程阻塞和喚醒切換以及用戶態內核態間的切換操作額外浪費消耗cpu資源；而CAS基於硬件實現，不需要進入內核，不需要切換線程，操作自旋機率較少，因此可以獲得更高的性能。
2、對於資源競爭嚴重（線程衝突嚴重）的情況，CAS自旋的概率會比較大，從而浪費更多的CPU資源，效率低於synchronized。
補充： synchronized在jdk1.6之後，已經改進優化。synchronized的底層實現主要依靠Lock-Free的隊列，基本思路是自旋後阻塞，競爭切換後繼續競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。在線程衝突較少的情況下，可以獲得和CAS類似的性能；而線程衝突嚴重的情況下，性能遠高於CAS。
concurrent包的實現：
由於java的CAS同時具有 volatile 讀和volatile寫的內存語義，因此Java線程之間的通信現在有了下面四種方式：
1. A線程寫volatile變量，隨後B線程讀這個volatile變量。
2. A線程寫volatile變量，隨後B線程用CAS更新這個volatile變量。
3. A線程用CAS更新一個volatile變量，隨後B線程用CAS更新這個volatile變量。
4. A線程用CAS更新一個volatile變量，隨後B線程讀這個volatile變量。
Java的CAS會使用現代處理器上提供的高效機器級別原子指令，這些原子指令以原子方式對內存執行讀-改-寫操作，這是在多處理器中實現同步的關鍵（從本質上來說，能夠支持原子性讀-改-寫指令的計算機器，是順序計算圖靈機的異步等價機器，因此任何現代的多處理器都會去支持某種能對內存執行原子性讀-改-寫操作的原子指令）。同時，volatile變量的讀/寫和CAS可以實現線程之間的通信。把這些特性整合在一起，就形成了整個concurrent包得以實現的基石。如果我們仔細分析concurrent包的源代碼實現，會發現一個通用化的實現模式：
1. 首先，聲明共享變量爲volatile；
2. 然後，使用CAS的原子條件更新來實現線程之間的同步；
3. 同時，配合以volatile的讀/寫和CAS所具有的volatile讀和寫的內存語義來實現線程之間的通信。
AbstractQueuedSynchronizer（AQS抽象的隊列同步器），atomic類，非堵塞數據結構這些concurrent包中的基礎類都是使用這種模式實現的，而concurrent包中的高層類又是依賴於這些基礎類實現的。concurrent包的整體示意圖如下：
JVM中的CAS（堆中對象的分配）：
Java調用new object()會創建一個對象，這個對象會被分配到JVM的堆中。那麼這個對象到底是怎麼在堆中保存的呢？
首先，new object()執行的時候，這個對象需要多大的空間，其實是已經確定的，因爲java中的各種數據類型，佔用多大的空間都是固定的（對其原理不清楚的請自行Google）。那麼接下來的工作就是在堆中找出那麼一塊空間用於存放這個對象。
在單線程的情況下，一般有兩種分配策略：
1. 指針碰撞：這種一般適用於內存是絕對規整的（內存是否規整取決於內存回收策略），分配空間的工作只是將指針像空閒內存一側移動對象大小的距離即可。
2. 空閒列表：這種適用於內存非規整的情況，這種情況下JVM會維護一個內存列表，記錄哪些內存區域是空閒的，大小是多少。給對象分配空間的時候去空閒列表裏查詢到合適的區域然後進行分配即可。
但是JVM不可能一直在單線程狀態下運行，那樣效率太差了。由於再給一個對象分配內存的時候不是原子性的操作，至少需要以下幾步：查找空閒列表、分配內存、修改空閒列表等等，這是不安全的。解決併發時的安全問題也有兩種策略：
1. CAS：實際上虛擬機採用CAS配合上失敗重試的方式保證更新操作的原子性，原理和上面講的一樣。
2. TLAB：如果使用CAS其實對性能還是會有影響的，所以JVM又提出了一種更高級的優化策略：每個線程在Java堆中預先分配一小塊內存，稱爲本地線程分配緩衝區（TLAB），線程內部需要分配內存時直接在TLAB上分配就行，避免了線程衝突。只有當緩衝區的內存用光需要重新分配內存的時候纔會進行CAS操作分配更大的內存空間。
虛擬機是否使用TLAB，可以通過-XX:+/-UseTLAB參數來進行配置（jdk5及以後的版本默認是啓用TLAB的）。