先看一段代碼：啟動兩個線程，每個線程中讓靜態變量count循環累加100次。

public class CountTest {public static int count = 0;public static void main(String[] args) {//開啟兩個線程for(int i = 0; i < 2; i++){new Thread(new Runnable(){public void run(){try{Thread.sleep(10);}catch(InterruptedException e){e.printStackTrace();}//每個線程中讓count自增100次for(int j = 0; j < 100; j++){count++;}}}).start();}try{Thread.sleep(2000);}catch(InterruptedException e){e.printStackTrace();}System.out.println("count=" + count);}}

幾次不同的運行結果：

? ???
因為這段代碼不是線程安全，所以最終的自增結果很可能會小于200.
方法一：加上synchronized同步鎖

public class CountTest {public static int count = 0;public static void main(String[] args) {//開啟兩個線程for(int i = 0; i < 2; i++){new Thread(new Runnable(){public void run(){try{Thread.sleep(10);}catch(InterruptedException e){e.printStackTrace();}//每個線程中讓count自增100次for(int j = 0; j < 100; j++){synchronized(CountTest.class){count++;}}}}).start();}try{Thread.sleep(2000);}catch(InterruptedException e){e.printStackTrace();}System.out.println("count=" + count);} }

（通過使用"類名.class"這個方式返回一個Class類型的對象，即獲取一個類的“類對象”）
加了同步鎖之后，count自增的操作變成了原子性操作，所以最終的輸出一定是count=200，代碼實現了線程安全。
synchronized雖然保證了線程安全，但在某些情況下，卻不是一個最優選擇。其關鍵在于性能問題。
synchronized取得的鎖都是對象鎖，而不是把一段代碼或方法當做鎖。因此在多線程訪問同一個對象時，哪個線程先執行synchronized關鍵字的方法，哪個線程就持有該方法所屬對象的鎖lock，其他線程只能呈等待狀態。
Synchronized關鍵字會讓沒有得到鎖資源的線程進入BLOCKED狀態，而后在爭奪到鎖資源后恢復為RUNNABLE狀態，這個過程中涉及到操作系統用戶模式和內核模式的轉換，代價比較高。
盡管Java1.6為Synchronized做了優化，增加了從偏向鎖到輕量級鎖再到重量級鎖的過度，但是在最終轉變為重量級鎖之后，性能仍然較低。

方法二：使用原子操作類

所謂原子操作類，指的是java.util.concurrent.atomic包下，一系列以Atomic開頭的包裝類。例如AtomicBoolean，AtomicInteger，AtomicLong。它們分別用于Boolean，Integer，Long類型的原子性操作。

在代碼中引入AtomicInteger類：

import java.util.concurrent.atomic.AtomicInteger;public class CountTest {public static AtomicInteger count = new AtomicInteger(0);public static void main(String[] args) {//開啟兩個線程for(int i = 0; i < 2; i++){new Thread(new Runnable(){public void run(){try{Thread.sleep(10);}catch(InterruptedException e){e.printStackTrace();}//每個線程中讓count自增100次for(int j = 0; j < 100; j++){ count.incrementAndGet(); }}}).start();}try{Thread.sleep(2000);}catch(InterruptedException e){e.printStackTrace();}System.out.println("count=" + count);} }

使用AtomicInteger之后，最終的輸出結果同樣可以保證是200。并且在某些情況下，代碼的性能會比Synchronized更好。
Atomic操作類的底層實現：Atomic操作類的底層實現用到的正是CAS機制。

什么是CAS?
CAS是英文單詞Compare And Swap的縮寫，翻譯過來就是比較并替換。
CAS機制當中使用了3個基本操作數：內存地址V，舊的預期值A，要修改的新值B。
更新一個變量的時候，只有當變量的預期值A和內存地址V當中的實際值相同時，才會將內存地址V對應的值修改為B。
舉個栗子：
1.在內存地址V當中，存儲著值為10的變量。

2.此時線程1想要把變量的值增加1。對線程1來說，舊的預期值A=10，要修改的新值B=11。

3.在線程1要提交更新之前，另一個線程2搶先一步，把內存地址V中的變量值率先更新成了11。

4.線程1開始提交更新，首先進行A和地址V的實際值比較（Compare），發現A不等于V的實際值，提交失敗。

5.線程1重新獲取內存地址V的當前值，并重新計算想要修改的新值。此時對線程1來說，A=11，B=12。這個重新嘗試的過程被稱為自旋。

?

6.這一次比較幸運，沒有其他線程改變地址V的值。線程1進行Compare，發現A和地址V的實際值是相等的。

7.線程1進行SWAP，把地址V的值替換為B，也就是12。

從思想上來說，Synchronized屬于悲觀鎖，悲觀地認為程序中的并發情況嚴重，所以嚴防死守。CAS屬于樂觀鎖，樂觀地認為程序中的并發情況不那么嚴重，所以讓線程不斷去嘗試更新。

CAS和Synchronized沒有絕對的好與壞，關鍵看使用場景。在并發量非常高的情況下，反而用同步鎖更合適一些。
CAS的應用：
1. Atomic系列類，以及Lock系列類的底層實現
2. 在Java1.6以上的版本，Synchronized轉變為重量級鎖之前，也會采用CAS機制。

CAS的缺點：
1.CPU開銷較大
在并發量比較高的情況下，如果許多線程反復嘗試更新某一個變量，卻又一直更新不成功，循環往復，會給CPU帶來很大的壓力。
2.不能保證代碼塊的原子性
CAS機制所保證的只是一個變量的原子性操作，而不能保證整個代碼塊的原子性。比如需要保證3個變量共同進行原子性的更新，就不得不使用Synchronized了。
3.ABA問題
這是CAS機制最大的問題所在。這里在下一篇說明。

參考：漫畫：什么是 CAS 機制？

來自公眾號：

轉載于:https://www.cnblogs.com/zeroingToOne/p/8955181.html

總結

以上是生活随笔為你收集整理的对CAS机制的理解（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。