悲觀者與樂觀者的做事方式完全不一樣,悲觀者的人生觀是一件事情我必須要百分之百完全控制才會去做,否則就認為這件事情一定會出問題;而樂觀者的人生觀則相反,凡事不管最終結果如何,他都會先嚐試去做,大不了最後不成功。這就是悲觀鎖與樂觀鎖的區別,悲觀鎖會把整個物件加鎖佔為自有後才去做操作,樂觀鎖不獲取鎖直接做操作,然後通過一定檢測手段決定是否更新資料。這一節將對樂觀鎖進行深入探討。
前面用Synchronized互斥鎖屬於悲觀鎖,它有一個明顯的缺點,它不管資料存不存在競爭都加鎖,隨著併發量增加,且如果鎖的時間比較長,其效能開銷將會變得很大。有沒有辦法解決這個問題?答案是基於衝突檢測的樂觀鎖。這種模式下,已經沒有所謂的鎖概念了,每條執行緒都直接先去執行操作,計算完成後檢測是否與其他執行緒存在共享資料競爭,如果沒有則讓此操作成功,如果存在共享資料競爭則可能不斷地重新執行操作和檢測,直到成功為止,可叫CAS自旋。
樂觀鎖的核心演算法是CAS(Compare and Swap),它涉及到三個運算元:記憶體值、預期值、新值。當且僅當預期值和記憶體值相等時才將記憶體值修改為新值。這樣處理的邏輯是,首先檢查某塊記憶體的值是否跟之前我讀取時的一樣,如不一樣則表示期間此記憶體值已經被別的執行緒更改過,捨棄本次操作,否則說明期間沒有其他執行緒對此記憶體值操作,可以把新值設定給此塊記憶體。如圖,有兩個執行緒可能會差不多同時對某記憶體操作,執行緒二先讀取某記憶體值作為預期值,執行到某處時執行緒二決定將新值設定到記憶體塊中,如果執行緒一在此期間修改了記憶體塊,則通過CAS即可以檢測出來,假如檢測沒問題則執行緒二將新值賦予記憶體塊。
你可能會發現一個疑問,比較和交換,從字面上就有兩個操作了,更別說實際CAS可能會有更多的執行指令,他們是原子性的嗎?如果非原子性又怎麼保證CAS操作期間出現併發帶來的問題?我是不是需要用上節提到的互斥鎖來保證他的原子性操作?CAS肯定是具有原子性的,不然就談不上在併發中使用了,但這個原子性是由CPU硬體指令實現保證的,即使用JNI呼叫native方法呼叫由C++編寫的硬體級別指令,jdk中提供了Unsafe類執行這些操作。另外,你可能想著CAS是通過互斥鎖來實現原子性的,這樣確實能實現,但用這種方式來保證原子性顯示毫無意義。下面一個虛擬碼加深對CAS的理解:public class AtomicInt {
private volatile int value;
public final int get() {
return value;
}
public final int getAndIncrement() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return current;
}
}
public final boolean compareAndSet(int expect, int update) {
Unsafe類提供的硬體級別的compareAndSwapInt方法;
}
}
複製程式碼
其中最重要的方法是getAndIncrement方法,它裡面實現了基於CAS的自旋。 現在已經瞭解樂觀鎖及CAS相關機制,樂觀鎖避免了悲觀鎖獨佔物件的現象,同時也提高了併發效能,但它也有缺點:
- 觀鎖只能保證一個共享變數的原子操作。如上例子,自旋過程中只能保證value變數的原子性,這時如果多一個或幾個變數,樂觀鎖將變得力不從心,但互斥鎖能輕易解決,不管物件數量多少及物件顆粒度大小。
- 長時間自旋可能導致開銷大。假如CAS長時間不成功而一直自旋,會給CPU帶來很大的開銷。
- ABA問題。CAS的核心思想是通過比對記憶體值與預期值是否一樣而判斷記憶體值是否被改過,但這個判斷邏輯不嚴謹,假如記憶體值原來是A,後來被一條執行緒改為B,最後又被改成了A,則CAS認為此記憶體值並沒有發生改變,但實際上是有被其他執行緒改過的,這種情況對依賴過程值的情景的運算結果影響很大。解決的思路是引入版本號,每次變數更新都把版本號加一。
樂觀鎖是對悲觀鎖的改進,雖然它也有缺點,但它確實已經成為提高併發效能的主要手段,而且jdk中的併發包也大量使用基於CAS的樂觀鎖。
-------------推薦閱讀------------
跟我交流,向我提問:
公眾號的選單已分為“分散式”、“機器學習”、“深度學習”、“NLP”、“Java深度”、“Java併發核心”、“JDK原始碼”、“Tomcat核心”等,可能有一款適合你的胃口。
歡迎關注: