樂觀鎖的實現機制--CAS(Compare And Set)
眾所周知鎖有兩種:樂觀鎖與悲觀鎖。
獨佔鎖是一種悲觀鎖,而 synchronized 就是一種獨佔鎖,synchronized 會導致其它所有未持有鎖的執行緒阻塞,而等待持有鎖的執行緒釋放鎖。
所謂樂觀鎖就是,每次不加鎖而是假設沒有衝突而去完成某項操作,如果因為衝突失敗就重試,直到成功為止。而樂觀鎖用到的機制就是CAS。
下面以一組漫畫來全面講解CAS,轉載來自於微信公眾號:“程式設計師小灰”
————— 第二天 —————
————————————
示例程式:啟動兩個執行緒,每個執行緒中讓靜態變數count迴圈累加100次。
最終輸出的count結果是什麼呢?一定會是200嗎?
加了同步鎖之後,count自增的操作變成了原子性操作,所以最終的輸出一定是count=200,程式碼實現了執行緒安全。
為什麼這麼說呢?關鍵在於效能問題。
Synchronized關鍵字會讓沒有得到鎖資源的執行緒進入BLOCKED狀態,而後在爭奪到鎖資源後恢復為RUNNABLE狀態,這個過程中涉及到作業系統使用者模式
儘管Java1.6為Synchronized做了優化,增加了從偏向鎖到輕量級鎖再到重量級鎖的過度,但是在最終轉變為重量級鎖之後,效能仍然較低。
jdk1.6以後 對synchronized鎖做了哪些優化
1.適應自旋鎖
自旋鎖:為了減少執行緒狀態改變帶來的消耗 不停地執行當前執行緒
2.鎖消除:
不可能存在共享資料競爭的鎖進行消除
3.鎖粗化:
將連續的加鎖 精簡到只加一次鎖
4.輕量級鎖:
無競爭條件下 通過CAS消除同步互斥
5.偏向鎖:
無競爭條件下 消除整個同步互斥,連CAS都不操作。
所謂原子操作類,指的是java.util.concurrent.atomic包下,一系列以Atomic開頭的包裝類。例如AtomicBoolean,AtomicInteger,AtomicLong。它們分別用於Boolean,Integer,Long型別的原子性操作。
現在我們嘗試在程式碼中引入AtomicInteger類:
使用AtomicInteger之後,最終的輸出結果同樣可以保證是200。並且在某些情況下,程式碼的效能會比Synchronized更好。
什麼是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的缺點:
1.CPU開銷較大
在併發量比較高的情況下,如果許多執行緒反覆嘗試更新某一個變數,卻又一直更新不成功,迴圈往復,會給CPU帶來很大的壓力。
2.不能保證程式碼塊的原子性
CAS機制所保證的只是一個變數的原子性操作,而不能保證整個程式碼塊的原子性。比如需要保證3個變數共同進行原子性的更新,就不得不使用Synchronized了。
因為它本身就只是一個鎖住匯流排的原子交換操作啊。兩個CAS操作之間並不能保證沒有重入現象。
3.ABA問題
這是CAS機制最大的問題所在。
什麼是ABA問題?怎麼解決?我們下一期來詳細介紹。