樂觀鎖&悲觀鎖&自旋鎖

文章目錄

• • 樂觀鎖&悲觀鎖&自旋鎖
  • 一、悲觀鎖
  • 二、樂觀鎖
  • 1.樂觀鎖常見的兩種實現方式
  • 2. 版本號機制
  • 3. CAS算法
  • 4. CAS缺點
  • 四、樂觀鎖和悲觀鎖的使用場景
  • 五、自旋鎖
  • 1.自旋鎖的原理
  • 2.自旋鎖的缺陷
  • 3.自旋鎖的使用場景

一、悲觀鎖

總是假設最壞的情況，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉讓給其它線程）。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

二、樂觀鎖

總是假設最好的情況，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號機制和CAS算法實現。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，像數據庫提供的類似于write_condition機制，其實都是提供的樂觀鎖。

1.樂觀鎖常見的兩種實現方式

2. 版本號機制

一般是在數據表中加上一個數據版本號version字段，表示數據被修改的次數。當數據被修改時，version值會加一。當線程A要更新數據值時，在讀取數據的同時也會讀取version值，在提交更新時，若剛才讀取到的version值為當前數據庫中的version值相等時才更新，否則重試更新操作，直到更新成功。

舉一個簡單的例子：

1.假設數據庫中帳戶信息表中有一個 $version$ 字段，當前值為 $1$ ；而當前帳戶余額字段（ $balance$ ）為 $$100$

2.當需要對賬戶信息表進行更新的時候，需要首先讀取version字段。

3.操作員 $A$ 此時將其讀出（ $version=1$ ），并從其帳戶余額中扣除 $50（ $100-$50 ）。
4. 在操作員 $A$操作的過程中，操作員$B$ 也讀入此用戶信息（ $version=1$），并從其帳戶余額中扣除 $20 （ $100-$20 ）。
5. 操作員 $A$完成了修改工作，提交更新之前會先看數據庫的版本和自己讀取到的版本是否一致，一致的話，就會將數據版本號加1（ $version=2$），連同帳戶扣除后余額（ $balance=$50$ ），提交至數據庫更新，
6.此時由于提交數據版本大于數據庫記錄當前版本，數據被更新，數據庫記錄
$version$ 更新為 $2$。 操作員 $B$
7.完成了操作，提交更新之前會先看數據庫的版本和自己讀取到的版本是否一致，但此時比對數據庫記錄版本時發現，操作員 $B$ 提交的數據版本號為 $2$
，而自己讀取到的版本號為$1$ ，不滿足 “ 當前最后更新的$version$與操作員第一次讀取的版本號相等 “ 的樂觀鎖策略，因此，操作員 B的提交被駁回。
8.這樣，就避免了操作員 $B$ 用基于 $version=1$ 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。

3. CAS算法

即compare and swap（比較與交換），是一種有名的無鎖算法。無鎖編程，即不使用鎖的情況下實現多線程之間的變量同步，也就是在沒有線程被阻塞的情況下實現變量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三個操作數:

• 需要讀寫的內存值 V
• 進行比較的值 E
• 擬寫入的新值 N

當且僅當 V 的值等于 A時，CAS通過原子方式用新值B來更新V的值，否則不會執行任何操作（比較和替換是一個原子操作）。一般情況下是一個自旋操作，即不斷的重試。

假如現在有兩個線程$t1$,$t2$,他們各自的運行環境中都有共享變量的副本$V1$、$V2$，預期值$E1$、$E2$，預期主存中的值還沒有被改變.

假設現在在并發環境，并且$t1$先拿到了執行權限，失敗的線程并不會被掛起，而是被告知這次競爭中失敗，并可以再次發起嘗試.

然后$t1$比較預期值$E1$和主存中的$V$，發現$E1=V$，說明預期值是正確的，執行$N1=V1+1$，并將$N1$的值傳入主存。這時候貯存中的$V=21$.

然后$t2$又緊接著拿到了執行權，比較$E2$和主存$V$的值，由于$V$已經被$t1$改為21，所以$E2!=V$，$t2$線程將主存中已經改變的值更新到自己的副本中，再發起重試；

直到預期值等于主存中的值，說明沒有別的線程對舊值進行修改，繼續執行代碼，退出；

4. CAS缺點

1.循環時間太長；

自旋CAS（也就是不成功就一直循環執行直到成功）如果長時間不成功，會給CPU帶來非常大的執行開銷。 如果JVM能支持處理器提供的pause指令那么效率會有一定的提升，pause指令有兩個作用，第一它可以延遲流水線執行指令（de-pipeline）,使CPU不會消耗過多的執行資源，延遲的時間取決于具體實現的版本，在一些處理器上延遲時間是零。第二它可以避免在退出循環的時候因內存順序沖突（memory order violation）而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執行效率。

2.只能保證一個共享變量原子操作；

CAS 只對單個共享變量有效，當操作涉及跨多個共享變量時 CAS 無效。但是從 JDK 1.5開始，提供了AtomicReference類來保證引用對象之間的原子性，你可以把多個變量放在一個對象里來進行 CAS 操作.所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合并成一個共享變量來操作。

3.會出現ABA問題；

如果一個變量V初次讀取的時候是A值，并且在準備賦值的時候檢查到它仍然是A值，那我們就能說明它的值沒有被其他線程修改過了嗎？很明顯是不能的，因為在這段時間它的值可能被改為其他值，然后又改回A，那CAS操作就會誤認為它從來沒有被修改過。這個問題被稱為CAS操作的 "ABA"問題。

JDK 1.5 以后的 AtomicStampedReference 類就提供了此種能力，其中的 compareAndSet 方法就是 首先檢查當前引用是否等于預期引用，并且當前標志是否等于預期標志，如果全部相等，則以原子方式將該引用和該標志的值設置為給定的更新值

四、樂觀鎖和悲觀鎖的使用場景

1.什么時候使用樂觀鎖？

資源提交沖突，其他使用方需要重新讀取資源，會增加讀的次數，但是可以面對高并發場景，前提是如果出現提交失敗，用戶是可以接受的。因此一般樂觀鎖只用在高并發、多讀少寫的場景。

其中：GIT,SVN,CVS等代碼版本控制管理器，就是一個樂觀鎖使用很好的場景，例如：A、B程序員，同時從SVN服務器上下載了code.html文件，當A完成提交后，此時B再提交，那么會報版本沖突，此時需要B進行版本處理合并后，再提交到服務器。這其實就是樂觀鎖的實現全過程。如果此時使用的是悲觀鎖，那么意味者所有程序員都必須一個一個等待操作提交完，才能訪問文件，這是難以接受的。

2.什么時候使用悲觀鎖？

一旦通過悲觀鎖鎖定一個資源，那么其他需要操作該資源的使用方，只能等待直到鎖被釋放，好處在于可以減少并發，但是當并發量非常大的時候，由于鎖消耗資源，并且可能鎖定時間過長，容易導致系統性能下降，資源消耗嚴重。因此一般我們可以在并發量不是很大，并且出現并發情況導致的異常用戶和系統都很難以接受的情況下，會選擇悲觀鎖進行。

總結：
CAS（比較并交換）是CPU指令級的操作，只有一步原子操作，所以非常快。而且CAS避免了請求操作系統來裁定鎖的問題，不需要進入內核，不需要切換線程，操作自旋幾率較少，因此可以獲得更高的性能不用麻煩操作系統，直接在CPU內部就搞定了

五、自旋鎖

何謂自旋鎖？它是為實現保護共享資源而提出一種鎖機制。

其實，自旋鎖與互斥鎖比較類似，它們都是為了解決對某項資源的互斥使用。無論是互斥鎖，還是自旋鎖，在任何時刻，最多只能有一個保持者，也就說，在任何時刻最多只能有一個執行單元獲得鎖。

但是兩者在調度機制上略有不同。

對于互斥鎖，如果資源已經被占用，資源申請者只能進入睡眠狀態。

但是自旋鎖不會引起調用者睡眠，如果自旋鎖已經被別的執行單元保持，調用者就一直循環在那里看是否該自旋鎖的保持者已經釋放了鎖，"自旋"一詞就是因此而得名

1.自旋鎖的原理

跟互斥鎖一樣，一個執行單元要想訪問被自旋鎖保護的共享資源，必須先得到鎖，在訪問完共享資源后，必須釋放鎖。

如果在獲取自旋鎖時，沒有任何執行單元保持該鎖，那么將立即得到鎖；

如果在獲取自旋鎖時鎖已經有保持者，那么獲取鎖操作將自旋在那里，一直去嘗試獲取鎖，直到該自旋鎖的保持者釋放了鎖。

2.自旋鎖的缺陷

死鎖。試圖遞歸地獲得自旋鎖必然會引起死鎖：遞歸程序的持有實例在第二個實例循環，以試圖獲得相同自旋鎖時，不會釋放此自旋鎖。在遞歸程序中使用自旋鎖應遵守下列策略：遞歸程序決不能在持有自旋鎖時調用它自己，也決不能在遞歸調用時試圖獲得相同的自旋鎖。此外如果一個進程已經將資源鎖定，那么，即使其它申請這個資源的進程不停地瘋狂“自旋”,也無法獲得資源，從而進入死循環。

過多占用cpu資源。如果不加限制，由于申請鎖的線程一直在循環等待，因此自旋鎖在鎖定的時候,如果不成功,不會睡眠,會持續的嘗試,單cpu的時候自旋鎖會讓其它process動不了. 因此，一般自旋鎖實現會有一個參數限定最多持續嘗試次數. 超出后, 自旋鎖放棄當前time slice. 等下一次機會。

3.自旋鎖的使用場景

自旋鎖比較適用于鎖使用者保持鎖時間比較短的情況。

• 正是由于自旋鎖使用者一般保持鎖時間非常短，因此選擇自旋而不是睡眠是非常必要的，自旋鎖的效率遠高于互斥鎖。
• 信號量和讀寫信號量適合于保持時間較長的情況，它們會導致調用者睡眠，因此只能在進程上下文使用，而自旋鎖適合于保持時間非常短的情況，它可以在任何上下文使用。
• 如果被保護的共享資源只在進程上下文訪問，使用信號量保護該共享資源非常合適，如果對共享資源的訪問時間非常短，自旋鎖也可以。
• 但是如果被保護的共享資源需要在中斷上下文訪問（包括底半部即中斷處理句柄和頂半部即軟中斷），就必須使用自旋鎖。
• 自旋鎖保持期間是搶占失效的，而信號量和讀寫信號量保持期間是可以被搶占的。自旋鎖只有在內核可搶占或SMP（多處理器）的情況下才真正需要，在單CPU且不可搶占的內核下，自旋鎖的所有操作都是空操作。

總結

以上是生活随笔為你收集整理的乐观锁悲观锁自旋锁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。