用跑車的鑰匙開啟樂觀鎖與悲觀鎖，並行效能風馳電掣！

前言：

在程式設計世界裡，「鎖」五花八門，多種多樣，每種鎖的加鎖開銷以及應用場景也可能會不同。近年來如何用好鎖，也是程式設計師的基本素養之一了。高並行的場景下，如果選對了合適的鎖，則會大大提高系統的效能，否則效能會降低。所以，知道各種鎖的開銷，以及應用場景是很有必要的。接下來，就談一談常見的這兩種鎖：悲觀鎖、樂觀鎖。

一、何謂悲觀鎖與樂觀鎖

另外本人整理了20年面試題大全，包含spring、並行、資料庫、Redis、分散式、dubbo、JVM、微服務等方面總結，下圖是部分截圖，需要的話點這裡點這裡，暗號CSDN。

樂觀鎖對應於生活中樂觀的人總是想著事情往好的方向發展，悲觀鎖對應於生
活中悲觀的人總是想著事情往壞的方向發展。這兩種人各有優缺點，不能不以
場景而定說一種人好於另外一種人。

悲觀鎖

總是假設最壞的情況，每次去拿資料的時候都認為別人會修改，所以每次在拿
資料的時候都會上鎖，這樣別人想拿這個資料就會阻塞直到它拿到鎖（ 共用資
源每次只給一個執行緒使用，其它執行緒阻塞，用完後再把資源轉讓給其它線
程）。

傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖
等，讀鎖，寫鎖等，都是在做操作之前先上鎖。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-blockingSynchronization）。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。

五、最後：

針對最近很多人都在面試，我這邊也整理了相當多的面試專題資料，也有其他大廠的面經。希望可以幫助到大家。

下面的面試題答案都整理成檔案筆記。也還整理了一些面試資料&最新2020收集的一些大廠的面試真題（都整理成檔案，小部分截圖），有需要的可以點選進入暗號CSDN