1. 程式人生 > 實用技巧 >你該懂的“鎖”知識!

你該懂的“鎖”知識!

你該懂的“鎖”知識!

生活中用到的鎖,用途都比較簡單粗暴,上鎖基本是為了防止外人進來。


文章目錄


前言

那在程式設計世界裡,「鎖」更是五花八門,多種多樣,每種鎖的加鎖開銷以及應用場景也可能會不同。如何用好鎖,也是程式設計師的基本素養之一。在高併發的場景下,如果選對了合適的鎖,則會大大提高系統的效能,否則效能會降低。


多執行緒訪問共享資源的時候,避免不了資源競爭而導致資料錯亂的問題,所以我們通常為了解決這一問題,都會在訪問共享資源之前加鎖。

為了選擇合適的鎖,我們不僅需要清楚知道加鎖的成本開銷有多大,還需要分析業務場景中訪問的共享資源的方式,再來還要考慮併發訪問共享資源時的衝突概率。

對症下藥,才能減少鎖對高併發效能的影響。那接下來,針對不同的應用場景,談一談互斥鎖、自旋鎖、讀寫鎖、樂觀鎖、悲觀鎖的選擇和使用。

一、互斥鎖與自旋鎖詳解

最底層的兩種就是會「互斥鎖和自旋鎖」,有很多高階的鎖都是基於它們實現的,你可以認為它們是各種鎖的地基,所以我們必須清楚它倆之間的區別和應用。

加鎖的目的就是保證共享資源在任意時間裡,只有一個執行緒訪問,這樣就可以避免多執行緒導致共享資料錯亂的問題。

當已經有一個執行緒加鎖後,其他執行緒加鎖則就會失敗,互斥鎖和自旋鎖對於加鎖失敗後的處理方式是不一樣的:

  • 互斥鎖加鎖失敗後,執行緒會釋放 CPU,給其他執行緒;
  • 自旋鎖加鎖失敗後,執行緒會忙等待,直到它拿到鎖;
    互斥鎖是一種獨佔鎖,比如當執行緒 A 加鎖成功後,此時互斥鎖已經被執行緒 A 獨佔了,只要執行緒 A 沒有釋放手中的鎖,執行緒 B 加鎖就會失敗,於是就會釋放 CPU 讓給其他執行緒,既然執行緒 B 釋放掉了 CPU,自然執行緒 B 加鎖的程式碼就會被阻塞。

對於互斥鎖加鎖失敗而阻塞的現象,是由作業系統核心實現的。當加鎖失敗時,核心會將執行緒置為「睡眠」狀態,等到鎖被釋放後,核心會在合適的時機喚醒執行緒,當這個執行緒成功獲取到鎖後,於是就可以繼續執行。
在這裡插入圖片描述
所以,互斥鎖加鎖失敗時,會從使用者態陷入到核心態

,讓核心幫我們切換執行緒,雖然簡化了使用鎖的難度,但是存在一定的效能開銷成本。
那這個開銷成本是什麼呢?會有兩次執行緒上下文切換的成本:

  • 當執行緒加鎖失敗時,核心會把執行緒的狀態從執行狀態設定為睡眠狀態,然後把 CPU 切換給其他執行緒執行;
  • 接著,當鎖被釋放時,之前睡眠狀態的執行緒會變為就緒狀態,然後核心會在合適的時間,把 CPU 切換給該執行緒執行。

執行緒的上下文切換的是什麼?當兩個執行緒是屬於同一個程序,因為虛擬記憶體是共享的,所以在切換時,虛擬記憶體這些資源就保持不動,只需要切換執行緒的私有資料、暫存器等不共享的資料。所以,如果你能確定被鎖住的程式碼執行時間很短,就不應該用互斥鎖,而應該選用自旋鎖,否則使用互斥鎖

自旋鎖是通過 CPU 提供的 CAS 函式(Compare And Swap),在使用者態完成加鎖和解鎖操作,不會主動產生執行緒上下文切換,所以相比互斥鎖來說,會快一些,開銷也小一些。
一般加鎖的過程,包含兩個步驟:

  1. 檢視鎖的狀態,如果鎖是空閒的,則執行第二步;
  2. 將鎖設定為當前執行緒持有;

CAS 函式就把這兩個步驟合併成一條硬體級指令,形成原子指令,這樣就保證了這兩個步驟是不可分割的,要麼一次性執行完兩個步驟,要麼兩個步驟都不執行。

使用自旋鎖的時候,當發生多執行緒競爭鎖的情況,加鎖失敗的執行緒會忙等待,直到它拿到鎖。這裡的忙等待可以用 while 迴圈等待實現,程式碼看起來像是個死迴圈,不過最好是使用 CPU 提供的 PAUSE 指令來實現,因為可以減少迴圈等待時的耗電量。

自旋鎖是最比較簡單的一種鎖,一直自旋,利用 CPU 週期,直到鎖可用

需要注意,在單核 CPU 上,需要搶佔式的排程器(即不斷通過時鐘中斷一個執行緒,執行其他執行緒)。否則,自旋鎖在單 CPU
上無法使用,因為一個自旋的執行緒永遠不會放棄 CPU。

自旋鎖開銷少,在多核系統下一般不會主動產生執行緒切換,適合非同步、協程等在使用者態切換請求的程式設計方式,但如果被鎖住的程式碼執行時間過長,自旋的執行緒會長時間佔用 CPU 資源,所以自旋的時間和被鎖住的程式碼執行的時間是成「正比」的關係,我們需要清楚的知道這一點。
自旋鎖與互斥鎖使用層面比較相似,但實現層面上完全不同:當加鎖失敗時,互斥鎖用「執行緒切換」來應對,自旋鎖則用「忙等待」來應對。

二、讀寫鎖

讀寫鎖從字面意思我們也可以知道,它由讀鎖和寫鎖兩部分構成,如果只讀取共享資源用讀鎖加鎖,如果要修改共享資源則用寫鎖加鎖。

所以,讀寫鎖適用於能明確區分讀操作和寫操作的場景。
讀寫鎖的工作原理是:

  • 當寫鎖沒有被執行緒持有時,多個執行緒能夠併發地持有讀鎖,這大大提高了共享資源的訪問效率,因為讀鎖是用於讀取共享資源的場景,所以多個執行緒同時持有讀鎖也不會破壞共享資源的資料。
  • 但是,一旦寫鎖被執行緒持有後,讀執行緒的獲取讀鎖的操作會被阻塞,而且其他寫執行緒的獲取寫鎖的操作也會被阻塞。

所以說,寫鎖是獨佔鎖,因為任何時刻只能有一個執行緒持有寫鎖,類似互斥鎖和自旋鎖而讀鎖是共享鎖,因為讀鎖可以被多個執行緒同時持有

知道了讀寫鎖的工作原理後,我們可以發現,讀寫鎖在讀多寫少的場景,能發揮出優勢。

另外,根據實現的不同,讀寫鎖可以分為讀優先鎖寫優先鎖

讀優先鎖期望的是,讀鎖能被更多的執行緒持有,以便提高讀執行緒的併發性,它的工作方式是:當讀執行緒 A 先持有了讀鎖,寫執行緒 B 在獲取寫鎖的時候,會被阻塞,並且在阻塞過程中,後續來的讀執行緒 C 仍然可以成功獲取讀鎖,最後直到讀執行緒 A 和 C 釋放讀鎖後,寫執行緒 B才可以成功獲取讀鎖。

寫優先鎖是優先服務寫執行緒,其工作方式是:當讀執行緒 A 先持有了讀鎖,寫執行緒 B 在獲取寫鎖的時候,會被阻塞,並且在阻塞過程中,後續來的讀執行緒 C 獲取讀鎖時會失敗,於是讀執行緒 C 將被阻塞在獲取讀鎖的操作,這樣只要讀執行緒 A 釋放讀鎖後,寫執行緒 B 就可以成功獲取讀鎖。

公平讀寫鎖比較簡單的一種方式是:用佇列把獲取鎖的執行緒排隊,不管是寫執行緒還是讀執行緒都按照先進先出的原則加鎖即可,這樣讀執行緒仍然可以併發,也不會出現飢餓的現象。

互斥鎖和自旋鎖都是最基本的鎖,讀寫鎖可以根據場景來選擇這兩種鎖其中的一個進行實現。

三、樂觀鎖與悲觀鎖

基本概念

樂觀鎖:在操作資料時非常樂觀,認為別人不會同時修改資料。因此樂觀鎖不會上鎖,只是在執行更新的時候判斷一下在此期間別人是否修改了資料:如果別人修改了資料則放棄操作,否則執行操作。另外,你會發現樂觀鎖全程並沒有加鎖,所以它也叫無鎖程式設計。

悲觀鎖:悲觀鎖在操作資料時比較悲觀,認為別人會同時修改資料。因此操作資料時直接把資料鎖住,直到操作完成後才會釋放鎖;上鎖期間其他人不能修改資料。

優缺點和適用場景

1、功能限制

與悲觀鎖相比,樂觀鎖適用的場景受到了更多的限制,無論是CAS還是版本號機制。

例如,CAS只能保證單個變數操作的原子性,當涉及到多個變數時,CAS是無能為力的,可以通過對整個程式碼塊加鎖來處理。再比如版本號機制,如果query的時候是針對表1,而update的時候是針對表2,也很難通過簡單的版本號來實現樂觀鎖。

2、競爭激烈程度
如果悲觀鎖和樂觀鎖都可以使用,那麼選擇就要考慮競爭的激烈程度:

當競爭不激烈 (出現併發衝突的概率小)時,樂觀鎖更有優勢,因為悲觀鎖會鎖住程式碼塊或資料,其他執行緒無法同時訪問,影響併發,而且加鎖和釋放鎖都需要消耗額外的資源。
當競爭激烈(出現併發衝突的概率大)時,悲觀鎖更有優勢,因為樂觀鎖在執行更新時頻繁失敗,需要不斷重試,浪費CPU資源。

四、CAS有哪些缺點?

1、ABA問題

假設有兩個執行緒——執行緒1和執行緒2,兩個執行緒按照順序進行以下操作:

(1)執行緒1讀取記憶體中資料為A;

(2)執行緒2將該資料修改為B;

(3)執行緒2將該資料修改為A;

(4)執行緒1對資料進行CAS操作

在第(4)步中,由於記憶體中資料仍然為A,因此CAS操作成功,但實際上該資料已經被執行緒2修改過了。這就是ABA問題。

在AtomicInteger的例子中,ABA似乎沒有什麼危害。但是在某些場景下,ABA卻會帶來隱患,例如棧頂問題:一個棧的棧頂經過兩次(或多次)變化又恢復了原值,但是棧可能已發生了變化。

對於ABA問題,比較有效的方案是引入版本號,記憶體中的值每發生一次變化,版本號都+1;在進行CAS操作時,不僅比較記憶體中的值,也會比較版本號,只有當二者都沒有變化時,CAS才能執行成功。

2、高競爭下的開銷問題

在併發衝突概率大的高競爭環境下,如果CAS一直失敗,會一直重試,CPU開銷較大。針對這個問題的一個思路是引入退出機制,如重試次數超過一定閾值後失敗退出。當然,更重要的是避免在高競爭環境下使用樂觀鎖。

3、功能限制

CAS的功能是比較受限的,例如CAS只能保證單個變數(或者說單個記憶體值)操作的原子性,這意味著:(1)原子性不一定能保證執行緒安全 (2)當涉及到多個變數(記憶體值)時,CAS也無能為力。

總結

不管使用的哪種鎖,我們的加鎖的程式碼範圍應該儘可能的小,也就是加鎖的粒度要小,這樣執行速度會比較快。再來,使用上了合適的鎖,就會快上加快了。