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

前言

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

但生活中也不是沒有 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 也是用了樂觀鎖的思想，先讓用戶編輯代碼，然后提交的時候，通過版本號來判斷是否產生了沖突，發生了沖突的地方，需要我們自己修改后，再重新提交，

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

總結

開發程序中，最常見的就是互斥鎖的了，互斥鎖加鎖失敗時，會用「執行緒切換」來應對，當加鎖失敗的執行緒再次加鎖成功后的這一程序，會有兩次執行緒背景關系切換的成本，性能損耗比較大，

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

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

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

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

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

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

不管使用的哪種鎖，我們的加鎖的代碼范圍應該盡可能的小，也就是加鎖的粒度要小，這樣執行速度會比較快，再來，使用上了合適的鎖，就會快上加快了，

絮叨

大家好，我是小林，微信公眾號：「小林coding」，一個專為大家圖解的工具人，更多更精彩的圖解文章，待你發掘！

如果覺得文章對你有幫助，歡迎分享給你的朋友，我們下次見！

推薦閱讀

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

萬粉福利，300 頁圖解網路 PDF 打包送你