用跑車的鑰匙打開樂觀鎖與悲觀鎖，并發性能風馳電掣！

前言：

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

一、何謂悲觀鎖與樂觀鎖

另外本人整理了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