1、什么是CAS？
CAS：Compare and Swap，即比較再交換，
jdk5增加了并發包java.util.concurrent.*,其下面的類使用CAS演算法實作了區別于synchronouse同步鎖的一種樂觀鎖，JDK 5之前Java語言是靠synchronized關鍵字保證同步的，這是一種獨占鎖，也是是悲觀鎖，
2、CAS演算法理解
對CAS的理解，CAS是一種無鎖演算法，CAS有3個運算元，記憶體值V，舊的預期值A，要修改的新值B，當且僅當預期值A和記憶體值V相同時，將記憶體值V修改為B，否則什么都不做，
CAS比較與交換的偽代碼可以表示為：
do{
備份舊資料；
基于舊資料構造新資料；
}while(!CAS( 記憶體地址，備份的舊資料，新資料 ))
注：t1，t2執行緒是同時更新同一變數56的值
因為t1和t2執行緒都同時去訪問同一變數56，所以他們會把主記憶體的值完全拷貝一份到自己的作業記憶體空間，所以t1和t2執行緒的預期值都為56，
假設t1在與t2執行緒競爭中執行緒t1能去更新變數的值，而其他執行緒都失敗，（失敗的執行緒并不會被掛起，而是被告知這次競爭中失敗，并可以再次發起嘗試），t1執行緒去更新變數值改為57，然后寫到記憶體中，此時對于t2來說，記憶體值變為了57，與預期值56不一致，就操作失敗了（想改的值不再是原來的值），
（上圖通俗的解釋是：CPU去更新一個值，但如果想改的值不再是原來的值，操作就失敗，因為很明顯，有其它操作先改變了這個值，）
就是指當兩者進行比較時，如果相等，則證明共享資料沒有被修改，替換成新值，然后繼續往下運行；如果不相等，說明共享資料已經被修改，放棄已經所做的操作，然后重新執行剛才的操作，容易看出 CAS 操作是基于共享資料不會被修改的假設，采用了類似于資料庫的commit-retry 的模式，當同步沖突出現的機會很少時，這種假設能帶來較大的性能提升，
3、CAS開銷
前面說過了，CAS（比較并交換）是CPU指令級的操作，只有一步原子操作，所以非常快，而且CAS避免了請求作業系統來裁定鎖的問題，不用麻煩作業系統，直接在CPU內部就搞定了，但CAS就沒有開銷了嗎？不！有cache miss的情況，這個問題比較復雜，首先需要了解CPU的硬體體系結構：
上圖可以看到一個8核CPU計算機系統，每個CPU有cache（CPU內部的高速快取，暫存器），管芯內還帶有一個互聯模塊，使管芯內的兩個核可以互相通信，在圖中央的系統互聯模塊可以讓四個管芯相互通信，并且將管芯與主存連接起來，資料以“快取線”為單位在系統中傳輸，“快取線”對應于記憶體中一個 2 的冪大小的位元組塊，大小通常為 32 到 256 位元組之間，當 CPU 從記憶體中讀取一個變數到它的暫存器中時，必須首先將包含了該變數的快取線讀取到 CPU 高速快取，同樣地，CPU 將暫存器中的一個值存盤到記憶體時，不僅必須將包含了該值的快取線讀到 CPU 高速快取，還必須確保沒有其他 CPU 擁有該快取線的拷貝，
比如，如果 CPU0 在對一個變數執行“比較并交換”（CAS）操作，而該變數所在的快取線在 CPU7 的高速快取中，就會發生以下經過簡化的事件序列：
-
CPU0 檢查本地高速快取，沒有找到快取線，
-
請求被轉發到 CPU0 和 CPU1 的互聯模塊，檢查 CPU1 的本地高速快取，沒有找到快取線，
-
請求被轉發到系統互聯模塊，檢查其他三個管芯，得知快取線被 CPU6和 CPU7 所在的管芯持有，
-
請求被轉發到 CPU6 和 CPU7 的互聯模塊，檢查這兩個 CPU 的高速快取，在 CPU7 的高速快取中找到快取線，
-
CPU7 將快取線發送給所屬的互聯模塊，并且重繪自己高速快取中的快取線，
-
CPU6 和 CPU7 的互聯模塊將快取線發送給系統互聯模塊，
-
系統互聯模塊將快取線發送給 CPU0 和 CPU1 的互聯模塊，
-
CPU0 和 CPU1 的互聯模塊將快取線發送給 CPU0 的高速快取，
-
CPU0 現在可以對高速快取中的變數執行 CAS 操作了
以上是重繪不同CPU快取的開銷，最好情況下的 CAS 操作消耗大概 40 納秒，超過 60 個時鐘周期，這里的“最好情況”是指對某一個變數執行 CAS 操作的 CPU 正好是最后一個操作該變數的CPU，所以對應的快取線已經在 CPU 的高速快取中了，類似地，最好情況下的鎖操作（一個“round trip 對”包括獲取鎖和隨后的釋放鎖）消耗超過 60 納秒，超過 100 個時鐘周期，這里的“最好情況”意味著用于表示鎖的資料結構已經在獲取和釋放鎖的 CPU 所屬的高速快取中了，鎖操作比 CAS 操作更加耗時，是因深入理解并行編程
為鎖操作的資料結構中需要兩個原子操作，快取未命中消耗大概 140 納秒，超過 200 個時鐘周期，需要在存盤新值時查詢變數的舊值的 CAS 操作，消耗大概 300 納秒，超過 500 個時鐘周期，想想這個，在執行一次 CAS 操作的時間里，CPU 可以執行 500 條普通指令，這表明了細粒度鎖的局限性，
以下是cache miss cas 和lock的性能對比：
4、CAS演算法在JDK中的應用
在原子類變數中，如java.util.concurrent.atomic中的AtomicXXX，都使用了這些底層的JVM支持為數字型別的參考型別提供一種高效的CAS操作，而在java.util.concurrent中的大多數類在實作時都直接或間接的使用了這些原子變數類，
Java 1.7中AtomicInteger.incrementAndGet()的實作原始碼為：
由此可見，AtomicInteger.incrementAndGet的實作用了樂觀鎖技術，呼叫了類sun.misc.Unsafe庫里面的 CAS演算法，用CPU指令來實作無鎖自增，所以，AtomicInteger.incrementAndGet的自增比用synchronized的鎖效率倍增，
近期熱文推薦：
1.Java 15 正式發布， 14 個新特性，重繪你的認知！！
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
4.吊打 Tomcat ，Undertow 性能很炸！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/241833.html
標籤：Java