本文講解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屬於樂觀鎖,樂觀地認爲程序中的併發情況不那麼嚴重,所以讓線程不斷去嘗試更新。
看到上面的解釋是不是索然無味,查找了很多資料也沒完全弄明白,通過幾次驗證後,終於明白,最終可以理解成一個無阻塞多線程爭搶資源的模型。先上代碼
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:"+Thread.currentThread().getName()+";flag:"+flag.get());
if (flag.compareAndSet(true,false)){
System.out.println(Thread.currentThread().getName()+""+flag.get());
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
flag.set(true);
}else{
System.out.println("重試機制thread:"+Thread.currentThread().getName()+";flag:"+flag.get());
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
run();
}
}
}
輸出的結果:
thread:Thread-1;flag:true
thread:Thread-0;flag:true
Thread-1false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:false
重試機制thread:Thread-0;flag:false
thread:Thread-0;flag:true
Thread-0false
這裏無論怎麼運行,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了。