面試必備樂觀鎖和悲觀鎖1

何謂悲觀鎖與樂觀鎖
樂觀鎖對應於生活中樂觀的人總是想着事情往好的方向發展，悲觀鎖對應於生
活中悲觀的人總是想着事情往壞的方向發展。這兩種人各有優缺點，不能不以
場景而定說一種人好於另外一種人。
悲觀鎖
總是假設最壞的情況，每次去拿數據的時候都認爲別人會修改，所以每次在拿
數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（ 共享資
源每次只給一個線程使用，其它線程阻塞，用完後再把資源轉讓給其它線
程）。傳統的關係型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖
等，讀鎖，寫鎖等，都是在做操作之前先上鎖。Java 中 synchronized 和
ReentrantLock 等獨佔鎖就是悲觀鎖思想的實現。
樂觀鎖
總是假設最好的情況，每次去拿數據的時候都認爲別人不會修改，所以不會上
鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以
使用版本號機制和 CAS 算法實現。 樂觀鎖適用於多讀的應用類型，這樣可以提
高吞吐量，像數據庫提供的類似於 write_condition  機制，其實都是提供的樂
觀鎖。在 Java 中 java.util.concurrent.atomic 包下面的原子變量類就是使用了
樂觀鎖的一種實現方式 CAS 實現的。
兩種鎖的使用場景
從上面對兩種鎖的介紹，我們知道兩種鎖各有優缺點，不可認爲一種好於另一
種，像 樂觀鎖適用於寫比較少的情況下（多讀場景），即衝突真的很少發生的
時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果是多寫的
情況，一般會經常產生衝突，這就會導致上層應用會不斷的進行 retry，這樣反
倒是降低了性能，所以 一般多寫的場景下用悲觀鎖就比較合適。
樂觀鎖常見的兩種實現方式
或 樂觀鎖一般會使用版本號機制或 CAS  算法實現。
1.  版本號機制
一般是在數據表中加上一個數據版本號 version 字段，表示數據被修改的次
數，當數據被修改時，version 值會加一。當線程 A 要更新數據值時，在讀取數
據的同時也會讀取 version 值，在提交更新時，若剛纔讀取到的 version 值爲當
前數據庫中的 version 值相等時才更新，否則重試更新操作，直到更新成功。
舉一個簡單的例子： 假設數據庫中帳戶信息表中有一個 version 字段，當前值
爲 1 ；而當前帳戶餘額字段（ balance ）爲 $100 。
1. 操作員 A 此時將其讀出（ version=1 ），並從其帳戶餘額中扣除 $50
（ $100-$50 ）。
2. 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息（
version=1 ），並從其帳戶餘額中扣除 $20 （ $100-$20 ）。
3. 操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同
帳戶扣除後餘額（ balance=$50 ），提交至數據庫更新，此時由於提
交數據版本大於數據庫記錄當前版本，數據被更新，數據庫記錄
version 更新爲 2 。
4. 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數據庫
提交數據（ balance=$80 ），但此時比對數據庫記錄版本時發現，操
作員 B 提交的數據版本號爲 2 ，數據庫記錄當前版本也爲 2 ，不滿
足 “ 提交版本必須大於記錄當前版本才能執行更新 “ 的樂觀鎖策略，
因此，操作員 B 的提交被駁回。
這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員
A 的操作結果的可能。
2. CAS  算法
即 compare and swap （比較與交換），是一種有名的 無鎖算法。無鎖編程，
即不使用鎖的情況下實現多線程之間的變量同步，也就是在沒有線程被阻塞的
情況下實現變量的同步，所以也叫非阻塞同步（Non-blocking
Synchronization）。CAS  算法涉及到三個操作數
 需要讀寫的內存值 V
 進行比較的值 A
 擬寫入的新值 B
當且僅當 V 的值等於 A 時，CAS 通過原子方式用新值 B 來更新 V 的值，否則
不會執行任何操作（比較和替換是一個原子操作）。一般情況下是一個 自旋操
作，即 不斷的重試。
關於自旋鎖，大家可以看一下這篇文章，非常不錯：《 面試必備之深入理解自
旋鎖》
樂觀鎖的缺點
ABA 問題是樂觀鎖一個常見的問題
1 ABA  問題
如果一個變量 V 初次讀取的時候是 A 值，並且在準備賦值的時候檢查到它仍然
是 A 值，那我們就能說明它的值沒有被其他線程修改過了嗎？很明顯是不能
的，因爲在這段時間它的值可能被改爲其他值，然後又改回 A，那 CAS 操作就
會誤認爲它從來沒有被修改過。這個問題被稱爲 CAS 操作的 "ABA" 問題。
JDK 1.5 以後的  AtomicStampedReference 類 就提供了此種能力，其中的
compareAndSet 方法 就是首先檢查當前引用是否等於預期引用，並且當前標誌是
否等於預期標誌，如果全部相等，則以原子方式將該引用和該標誌的值設置爲
給定的更新值。
2  循環時間長開銷大
旋 自旋 CAS （也就是不成功就一直循環執行直到成功）如果長時間不成功，會給
CPU  帶來非常大的執行開銷。 如果 JVM 能支持處理器提供的 pause 指令那麼
效率會有一定的提升，pause 指令有兩個作用，第一它可以延遲流水線執行指
令（de-pipeline）,使 CPU 不會消耗過多的執行資源，延遲的時間取決於具體
實現的版本，在一些處理器上延遲時間是零。第二它可以避免在退出循環的時
候因內存順序衝突（memory order violation）而引起 CPU 流水線被清空
（CPU pipeline flush），從而提高 CPU 的執行效率。
3  只能保證一個共享變量的原子操作
CAS 只對單個共享變量有效，當操作涉及跨多個共享變量時 CAS 無效。但是
從 JDK 1.5 開始，提供了 AtomicReference 類 來保證引用對象之間的原子性，你
可以把多個變量放在一個對象裏來進行 CAS 操作.所以我們可以使用鎖或者利
用 AtomicReference 類 把多個共享變量合併成一個共享變量來操作。
CAS 與 與 synchronized  的使用情景
說 簡單的來說 CAS  適用於寫比較少的情況下（多讀場景，衝突一般較少），
synchronized  適用於寫比較多的情況下（多寫場景，衝突一般較多）
1. 對於資源競爭較少（線程衝突較輕）的情況，使用 synchronized 同步鎖
進行線程阻塞和喚醒切換以及用戶態內核態間的切換操作額外浪費消耗
cpu 資源；而 CAS 基於硬件實現，不需要進入內核，不需要切換線程，
操作自旋機率較少，因此可以獲得更高的性能。
2. 對於資源競爭嚴重（線程衝突嚴重）的情況，CAS 自旋的概率會比較
大，從而浪費更多的 CPU 資源，效率低於 synchronized。
補充： Java 併發編程這個領域中 synchronized 關鍵字一直都是元老級的角
色，很久之前很多人都會稱它爲 “ 重量級鎖” 。但是，在 JavaSE 1.6 之後進行了
主要包括爲了減少獲得鎖和釋放鎖帶來的性能消耗而引入的  偏向鎖 和  輕量級
鎖 鎖 以及其它 各種優化之後變得在某些情況下並不是那麼重了。synchronized 的
底層實現主要依靠 Lock-Free 的隊列，基本思路是  自旋後阻塞， 競爭切換後繼
續競爭鎖， 稍微犧牲了公平性，但獲得了高吞吐量。在線程衝突較少的情況
下，可以獲得和 CAS 類似的性能；而線程衝突嚴重的情況下，性能遠高於
CAS。
更多免費技術資料可關注：annalin1203