本文講解CAS機制，主要是因爲最近準備面試題，發現這個問題在面試中出現的頻率非常的高，因此把自己學習過程中的一些理解記錄下來，希望能對大家也有幫助。
什麼是悲觀鎖、樂觀鎖？在java語言裏，總有一些名詞看語義跟本不明白是啥玩意兒，也就總有部分面試官拿着這樣的詞來忽悠面試者，以此來找優越感，其實理解清楚了，這些詞也就唬不住人了。
- synchronized是悲觀鎖，這種線程一旦得到鎖，其他需要鎖的線程就掛起的情況就是悲觀鎖。
- CAS操作的就是樂觀鎖，每次不加鎖而是假設沒有衝突而去完成某項操作，如果因爲衝突失敗就重試，直到成功爲止。
在進入正題之前，我們先理解下下面的代碼:
private static int count = 0;
public static void main(String[] args) {
for (int i = 0; i < 2; i++) {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(10);
} catch (Exception e) {
e.printStackTrace();
}
//每個線程讓count自增100次
for (int i = 0; i < 100; i++) {
count++;
}
}
}).start();
}
try{
Thread.sleep(2000);
}catch (Exception e){
e.printStackTrace();
}
System.out.println(count);
}
請問cout的輸出值是否爲200？答案是否定的，因爲這個程序是線程不安全的，所以造成的結果count值可能小於200;
那麼如何改造成線程安全的呢，其實我們可以使用上Synchronized同步鎖,我們只需要在count++的位置添加同步鎖，代碼如下:
private static int count = 0;
public static void main(String[] args) {
for (int i = 0; i < 2; i++) {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(10);
} catch (Exception e) {
e.printStackTrace();
}
//每個線程讓count自增100次
for (int i = 0; i < 100; i++) {
synchronized (ThreadCas.class){
count++;
}
}
}
}).start();
}
try{
Thread.sleep(2000);
}catch (Exception e){
e.printStackTrace();
}
System.out.println(count);
}
加了同步鎖之後，count自增的操作變成了原子性操作，所以最終的輸出一定是count=200，代碼實現了線程安全。
但是Synchronized雖然確保了線程的安全，但是在性能上卻不是最優的，Synchronized關鍵字會讓沒有得到鎖資源的線程進入BLOCKED狀態，而後在爭奪到鎖資源後恢復爲RUNNABLE狀態，這個過程中涉及到操作系統用戶模式和內核模式的轉換，代價比較高。
儘管Java1.6爲Synchronized做了優化，增加了從偏向鎖到輕量級鎖再到重量級鎖的過度，但是在最終轉變爲重量級鎖之後，性能仍然較低。
所謂原子操作類，指的是java.util.concurrent.atomic包下，一系列以Atomic開頭的包裝類。例如AtomicBoolean，AtomicInteger，AtomicLong。它們分別用於Boolean，Integer，Long類型的原子性操作。
private static AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) {
for (int i = 0; i < 2; i++) {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(10);
} catch (Exception e) {
e.printStackTrace();
}
//每個線程讓count自增100次
for (int i = 0; i < 100; i++) {
count.incrementAndGet();
}
}
}).start();
}
try{
Thread.sleep(2000);
}catch (Exception e){
e.printStackTrace();
}
System.out.println(count);
}
使用AtomicInteger之後，最終的輸出結果同樣可以保證是200。並且在某些情況下，代碼的性能會比Synchronized更好。
而Atomic操作的底層實現正是利用的CAS機制，好的，我們切入到這個博客的正點。
什麼是CAS機制
CAS是英文單詞Compare And Swap的縮寫，翻譯過來就是比較並替換。
CAS機制當中使用了3個基本操作數：內存地址V，舊的預期值A，要修改的新值B。
更新一個變量的時候，只有當變量的預期值A和內存地址V當中的實際值相同時，纔會將內存地址V對應的值修改爲B。
CAS是英文單詞Compare And Swap的縮寫，翻譯過來就是比較並替換。
CAS機制當中使用了3個基本操作數：內存地址V，舊的預期值A，要修改的新值B。
更新一個變量的時候，只有當變量的預期值A和內存地址V當中的實際值相同時，纔會將內存地址V對應的值修改爲B。
這樣說或許有些抽象，我們來看一個例子：
1.在內存地址V當中，存儲着值爲10的變量。
image
2.此時線程1想要把變量的值增加1。對線程1來說，舊的預期值A=10，要修改的新值B=11。
image
3.在線程1要提交更新之前，另一個線程2搶先一步，把內存地址V中的變量值率先更新成了11。
image
4.線程1開始提交更新，首先進行A和地址V的實際值比較（Compare），發現A不等於V的實際值，提交失敗。
4.jpg
5.線程1重新獲取內存地址V的當前值，並重新計算想要修改的新值。此時對線程1來說，A=11，B=12。這個重新嘗試的過程被稱爲自旋。
image
6.這一次比較幸運，沒有其他線程改變地址V的值。線程1進行Compare，發現A和地址V的實際值是相等的。
image
7.線程1進行SWAP，把地址V的值替換爲B，也就是12。
image
從思想上來說，Synchronized屬於悲觀鎖，悲觀地認爲程序中的併發情況嚴重，所以嚴防死守。CAS屬於樂觀鎖，樂觀地認爲程序中的併發情況不那麼嚴重，所以讓線程不斷去嘗試更新。
看到上面的解釋是不是索然無味，查找了很多資料也沒完全弄明白，通過幾次驗證後，終於明白，最終可以理解成一個無阻塞多線程爭搶資源的模型。先上代碼
package LambdaTest;
import java.util.concurrent.atomic.AtomicBoolean;
/**
* @author hrabbit
* 2018/07/16.
*/
public class AtomicBooleanTest implements Runnable {
private static AtomicBoolean flag = new AtomicBoolean(true);
public static void main(String[] args) {
AtomicBooleanTest ast = new AtomicBooleanTest();
Thread thread1 = new Thread(ast);
Thread thread = new Thread(ast);
thread1.start();
thread.start();
}
@Override
public void run() {
System.out.println("初始值：:"+Thread.currentThread().getName()+";flag:"+flag.get());
//compareAndSet 其實也是加鎖操作，不過這個操作是cpu彙編指令級別的 但是yao比syno...好很多很多
if (flag.compareAndSet(true,false)){
System.out.println("CAS內部："+Thread.currentThread().getName()+""+flag.get());
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
flag.set(true);
}else{
System.out.println("重試線程:"+Thread.currentThread().getName()+";flag:"+flag.get());
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
run();
}
}
}
輸出的結果:
初始值：:Thread-0;flag:true
初始值：:Thread-1;flag:true
CAS內部：Thread-0false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:false
重試線程:Thread-1;flag:false
初始值：:Thread-1;flag:true
CAS內部：Thread-1false
這裏無論怎麼運行，Thread-1、Thread-0都會執行if=true條件，而且還不會產生線程髒讀髒寫，這是如何做到的了，這就用到了我們的compareAndSet(boolean expect,boolean update)方法
我們看到當Thread-1在進行操作的時候，Thread一直在進行重試機制，程序原理圖:
image
這個圖中重最要的是compareAndSet(true,false)方法要拆開成compare(true)方法和Set(false)方法理解，是compare(true)是等於true後，就馬上設置共享內存爲false，這個時候，其它線程無論怎麼走都無法走到只有得到共享內存爲true時的程序隔離方法區。
看到這裏，這種CAS機制就是完美的嗎？這個程序其實存在一個問題，不知道大家注意到沒有？
但是這種得不到狀態爲true時使用遞歸算法是很耗cpu資源的，所以一般情況下，都會有線程sleep。
CAS的缺點：
1.CPU開銷較大
在併發量比較高的情況下，如果許多線程反覆嘗試更新某一個變量，卻又一直更新不成功，循環往復，會給CPU帶來很大的壓力。
2.不能保證代碼塊的原子性
CAS機制所保證的只是一個變量的原子性操作，而不能保證整個代碼塊的原子性。比如需要保證3個變量共同進行原子性的更新，就不得不使用Synchronized了。
作者：Flagle
鏈接：https://www.jianshu.com/p/ae25eb3cfb5d
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。