面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

小林coding 發表於 2020-09-15
面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

前言

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

但生活中也不是沒有 BUG 的,比如加鎖的電動車在「廣西 - 竊·格瓦拉」面前,鎖就是形同虛設,只要他願意,他就可以輕輕鬆鬆地把你電動車給「順走」,不然打工怎麼會是他這輩子不可能的事情呢?牛逼之人,必有牛逼之處。

面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

那在程式設計世界裡,「鎖」更是五花八門,多種多樣,每種鎖的加鎖開銷以及應用場景也可能會不同。

如何用好鎖,也是程式設計師的基本素養之一了。

高併發的場景下,如果選對了合適的鎖,則會大大提高系統的效能,否則效能會降低。

所以,知道各種鎖的開銷,以及應用場景是很有必要的。

接下來,就談一談常見的這幾種鎖:

面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

正文

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

最常用的就是互斥鎖,當然還有很多種不同的鎖,比如自旋鎖、讀寫鎖、樂觀鎖等,不同種類的鎖自然適用於不同的場景。

如果選擇了錯誤的鎖,那麼在一些高併發的場景下,可能會降低系統的效能,這樣使用者體驗就會非常差了。

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

對症下藥,才能減少鎖對高併發效能的影響。

那接下來,針對不同的應用場景,談一談「互斥鎖、自旋鎖、讀寫鎖、樂觀鎖、悲觀鎖」的選擇和使用。

互斥鎖與自旋鎖:誰更輕鬆自如?

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

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

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

  • 互斥鎖加鎖失敗後,執行緒會釋放 CPU ,給其他執行緒;
  • 自旋鎖加鎖失敗後,執行緒會忙等待,直到它拿到鎖;

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

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

面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

所以,互斥鎖加鎖失敗時,會從使用者態陷入到核心態,讓核心幫我們切換執行緒,雖然簡化了使用鎖的難度,但是存在一定的效能開銷成本。

那這個開銷成本是什麼呢?會有兩次執行緒上下文切換的成本

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

執行緒的上下文切換的是什麼?當兩個執行緒是屬於同一個程式,因為虛擬記憶體是共享的,所以在切換時,虛擬記憶體這些資源就保持不動,只需要切換執行緒的私有資料、暫存器等不共享的資料。

上下切換的耗時有大佬統計過,大概在幾十納秒到幾微秒之間,如果你鎖住的程式碼執行時間比較短,那可能上下文切換的時間都比你鎖住的程式碼執行時間還要長。

所以,如果你能確定被鎖住的程式碼執行時間很短,就不應該用互斥鎖,而應該選用自旋鎖,否則使用互斥鎖。

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

一般加鎖的過程,包含兩個步驟:

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

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

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

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

自旋鎖開銷少,在多核系統下一般不會主動產生執行緒切換,適合非同步、協程等在使用者態切換請求的程式設計方式,但如果被鎖住的程式碼執行時間過長,自旋的執行緒會長時間佔用 CPU 資源,所以自旋的時間和被鎖住的程式碼執行的時間是成「正比」的關係,我們需要清楚的知道這一點。

自旋鎖與互斥鎖使用層面比較相似,但實現層面上完全不同:當加鎖失敗時,互斥鎖用「執行緒切換」來應對,自旋鎖則用「忙等待」來應對

它倆是鎖的最基本處理方式,更高階的鎖都會選擇其中一個來實現,比如讀寫鎖既可以選擇互斥鎖實現,也可以基於自旋鎖實現。


讀寫鎖:讀和寫還有優先順序區分?

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

所以,讀寫鎖適用於能明確區分讀操作和寫操作的場景

讀寫鎖的工作原理是:

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

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

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

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

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

面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

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

面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

讀優先鎖對於讀執行緒併發性更好,但也不是沒有問題。我們試想一下,如果一直有讀執行緒獲取讀鎖,那麼寫執行緒將永遠獲取不到寫鎖,這就造成了寫執行緒「飢餓」的現象。

寫優先鎖可以保證寫執行緒不會餓死,但是如果一直有寫執行緒獲取寫鎖,讀執行緒也會被「餓死」。

既然不管優先讀鎖還是寫鎖,對方可能會出現餓死問題,那麼我們就不偏袒任何一方,搞個「公平讀寫鎖」。

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

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


樂觀鎖與悲觀鎖:做事的心態有何不同?

前面提到的互斥鎖、自旋鎖、讀寫鎖,都是屬於悲觀鎖。

悲觀鎖做事比較悲觀,它認為多執行緒同時修改共享資源的概率比較高,於是很容易出現衝突,所以訪問共享資源前,先要上鎖

那相反的,如果多執行緒同時修改共享資源的概率比較低,就可以採用樂觀鎖。

樂觀鎖做事比較樂觀,它假定衝突的概率很低,它的工作方式是:先修改完共享資源,再驗證這段時間內有沒有發生衝突,如果沒有其他執行緒在修改資源,那麼操作完成,如果發現有其他執行緒已經修改過這個資源,就放棄本次操作

放棄後如何重試,這跟業務場景息息相關,雖然重試的成本很高,但是衝突的概率足夠低的話,還是可以接受的。

可見,樂觀鎖的心態是,不管三七二十一,先改了資源再說。另外,你會發現樂觀鎖全程並沒有加鎖,所以它也叫無鎖程式設計

這裡舉一個場景例子:線上文件。

我們都知道線上文件可以同時多人編輯的,如果使用了悲觀鎖,那麼只要有一個使用者正在編輯文件,此時其他使用者就無法開啟相同的文件了,這使用者體驗當然不好了。

那實現多人同時編輯,實際上是用了樂觀鎖,它允許多個使用者開啟同一個文件進行編輯,編輯完提交之後才驗證修改的內容是否有衝突。

怎麼樣才算發生衝突?這裡舉個例子,比如使用者 A 先在瀏覽器編輯文件,之後使用者 B 在瀏覽器也開啟了相同的文件進行編輯,但是使用者 B 比使用者 A 提交改動,這一過程使用者 A 是不知道的,當 A 提交修改完的內容時,那麼 A 和 B 之間並行修改的地方就會發生衝突。

服務端要怎麼驗證是否衝突了呢?通常方案如下:

  • 由於發生衝突的概率比較低,所以先讓使用者編輯文件,但是瀏覽器在下載文件時會記錄下服務端返回的文件版本號;
  • 當使用者提交修改時,發給服務端的請求會帶上原始文件版本號,伺服器收到後將它與當前版本號進行比較,如果版本號一致則修改成功,否則提交失敗。

實際上,我們常見的 SVN 和 Git 也是用了樂觀鎖的思想,先讓使用者編輯程式碼,然後提交的時候,通過版本號來判斷是否產生了衝突,發生了衝突的地方,需要我們自己修改後,再重新提交。

樂觀鎖雖然去除了加鎖解鎖的操作,但是一旦發生衝突,重試的成本非常高,所以只有在衝突概率非常低,且加鎖成本非常高的場景時,才考慮使用樂觀鎖。


總結

開發過程中,最常見的就是互斥鎖的了,互斥鎖加鎖失敗時,會用「執行緒切換」來應對,當加鎖失敗的執行緒再次加鎖成功後的這一過程,會有兩次執行緒上下文切換的成本,效能損耗比較大。

如果我們明確知道被鎖住的程式碼的執行時間很短,那我們應該選擇開銷比較小的自旋鎖,因為自旋鎖加鎖失敗時,並不會主動產生執行緒切換,而是一直忙等待,直到獲取到鎖,那麼如果被鎖住的程式碼執行時間很短,那這個忙等待的時間相對應也很短。

如果能區分讀操作和寫操作的場景,那讀寫鎖就更合適了,它允許多個讀執行緒可以同時持有讀鎖,提高了讀的併發性。根據偏袒讀方還是寫方,可以分為讀優先鎖和寫優先鎖,讀優先鎖併發性很強,但是寫執行緒會被餓死,而寫優先鎖會優先服務寫執行緒,讀執行緒也可能會被餓死,那為了避免飢餓的問題,於是就有了公平讀寫鎖,它是用佇列把請求鎖的執行緒排隊,並保證先入先出的原則來對執行緒加鎖,這樣便保證了某種執行緒不會被餓死,通用性也更好點。

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

另外,互斥鎖、自旋鎖、讀寫鎖都屬於悲觀鎖,悲觀鎖認為併發訪問共享資源時,衝突概率可能非常高,所以在訪問共享資源前,都需要先加鎖。

相反的,如果併發訪問共享資源時,衝突概率非常低的話,就可以使用樂觀鎖,它的工作方式是,在訪問共享資源時,不用先加鎖,修改完共享資源後,再驗證這段時間內有沒有發生衝突,如果沒有其他執行緒在修改資源,那麼操作完成,如果發現有其他執行緒已經修改過這個資源,就放棄本次操作。

但是,一旦衝突概率上升,就不適合使用樂觀鎖了,因為它解決衝突的重試成本非常高。

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


絮叨

這週末忙裡偷閒了下,看了三部電影,簡單說一下感受。

首先看了「利刃出鞘」,這部電影是懸疑型別,也是豆瓣高分電影,電影雖然沒有什麼大場面,但是單純靠縝密的劇情鋪設,全程無尿點,結尾也各種翻轉,如果喜歡懸疑類電影朋友,不妨抽個時間看看。

再來,看了「花木蘭」,這電影我特喵無法可說,爛片中的戰鬥雞,演員都是中國人卻全在說英文(導演是美國迪士尼的),這種感覺就很奇怪很彆扭,好比你看西遊記、水滸傳英文版那樣的彆扭。彆扭也就算了,關鍵劇情平淡無奇,各種無厘頭的地方,反正看完之後,我非常後悔把我生命中非常珍貴的 2 個小時獻給了它,如果能重來,我選擇用這 2 小時睡覺。

最後,當然看了「信條」,諾蘭用巨資拍攝出來的電影,花錢買飛機來撞,畫面非常震撼,可以說非常有誠意了。諾蘭鍾愛時間的概念,這次則以時間倒流方式來呈現,非常的燒腦,反正我看完後腦袋懵懵的,我就是要這種感覺,嘻嘻。

面試官:你說說互斥鎖、自旋鎖、讀寫鎖、悲觀鎖、樂觀鎖的應用場景

大家好,我是小林,一個專為大家圖解的工具人,如果覺得文章對你有幫助,歡迎分享給你的朋友,我們下次見!


推薦閱讀

多個執行緒為了同個資源打起架來了,該如何讓他們安分?