CAS（compare and swap）是解決多線程并行情況下使用鎖造成性能損耗的一種機(jī)制。多線程CAS操作包含3個操作數(shù)，分別是內(nèi)存位置V、預(yù)期原值A(chǔ)和新值B。如果內(nèi)存位置的值與預(yù)期原值相匹配，那么處理器會自動將該位置值更新為新值。否則，處理器不做任何操作。無論哪種情況，它都會在CAS指令之前返回該位置的值。多線程CAS有效地說明了“我認(rèn)為位置V應(yīng)該包含值A(chǔ)；如果包含該值，則將B放到這個位置；否則，不要更改該位置，只告訴我這個位置現(xiàn)在的值即可。

這些處理過程有指令集的支持，因此看似讀-寫-改操作只是一個原子操作，所以不存在線程安全問題。我們看個cas的操作過程偽代碼:

int value ;

int compareAndSwap (int oldValue,int newValue){

int old_reg_value =value ;

if (old_reg_value==old_reg_value)

value =newValue;

return old_reg_value ;

 }

當(dāng)多個線程嘗試使用CAS同時更新同一個變量的時候，只有其中一個線程能夠更新變量的值。當(dāng)其他線程失敗后，不會像獲取鎖一樣被掛起，而是可以再次嘗試，或者不進(jìn)行任何操作，這種靈活性就大大減少了鎖活躍性風(fēng)險。

CAS的特性決定了CAS的功能和作用，我們知道采用鎖對共享數(shù)據(jù)進(jìn)行處理的話，當(dāng)多個線程競爭的時候，都需要進(jìn)行加鎖，沒有拿到鎖的線程會被阻塞，以及喚醒，這些都需要用戶態(tài)到核心態(tài)的轉(zhuǎn)換，這個代價對阻塞線程來說代價還是蠻高的，那cas是采用無鎖樂觀方式進(jìn)行競爭，性能上要比鎖更高些才是，為何不對鎖競爭方式進(jìn)行替換？

要回答這個問題，我們先舉個例子。當(dāng)你開車在上班高峰期的時候，如果通過交通信號燈來控制車流，可以實現(xiàn)更高的吞吐量，而環(huán)島雖然無紅綠燈讓你等待，但你一圈不一定能繞出你先出去的那個路口，有時候可能得多走幾圈，而在低擁堵的時候，環(huán)島則能實現(xiàn)更高的吞吐量，你一次就可以成功，而紅路燈反而效率低下了，即便人不多，你依然需要等待。

這個例子依然適應(yīng)鎖和cas的比較，在高度競爭的情況下，鎖的性能將超過cas的性能，但在中低程度的競爭情況下，cas性能將超過鎖的性能。多數(shù)情況下，資源競爭一般都不會那么激烈。

我們參考一個ConcurrentLinkedQueue 的源碼實現(xiàn)，來看下cas的應(yīng)用。

ConcurrentLinkedQueue是一個基于鏈接節(jié)點的無界線程安全隊列，它是個單向鏈表，每個鏈接節(jié)點都擁有一個當(dāng)前節(jié)點的元素和下一個節(jié)點的指針。

 Node< E> {

volatile E item;

volatile Node< E> next;

}

它采用先進(jìn)先出的規(guī)則對節(jié)點進(jìn)行排序，當(dāng)我們添加一個元素的時候，它會添加到隊列的尾部（tail），當(dāng)我們獲取一個元素時，它會返回隊列頭部(head)的元素。tail節(jié)點和head節(jié)點方便我們快速定位最后一個和第一個元素。

在有兩次CAS操作的情況下，如何保證一致性呢？具體分為三種情況如下：

1、如果第一個cas更新成功，第二個失敗，那么對了tail會出現(xiàn)不一致的情況。而且即便是都更新成功了，在執(zhí)行兩個cas之間，仍然可能有另外一個線程會訪問這個隊列，那么如何保證這種多線程情況下不會出錯。

2、對于第一個問題，即便tail更新失敗，上述代碼也會循環(huán)的找到真正的尾節(jié)點，在這里不是強(qiáng)制要求以tail為尾節(jié)點，它只是一個靠近尾節(jié)點的指針。

3、第二種情況，如果線程B抵達(dá)時候，發(fā)現(xiàn)線程A正在執(zhí)行更新，那么B線程會通過反復(fù)循環(huán)來檢查隊列的狀態(tài)，直到A完成更新，B線程又拿到了nextNode最新信息，添加新的node,從而使兩個線程不會相互干擾。

講了那么多，還是離不開CAS解決多線程并行情況下使用鎖造成性能損耗的本質(zhì)，萬變不離其宗，只要我們掌握了這一點學(xué)起多線程CAS也就事半功倍了。在本站的多線程教程中還有更多的多線程的各種奇特的機(jī)制的詳細(xì)解析，幫助我們更好地學(xué)習(xí)多線程知識。