以下文章來源于小林coding ，作者小林coding
前言
生活中用到的鎖，用途都比較簡單粗暴，上鎖基本是為了防止外人進來、電動車被偷等等。
但生活中也不是沒有 BUG 的，比如加鎖的電動車在「廣西 - 竊·格瓦拉」面前，鎖就是形同虛設，隻要他願意，他就可以輕輕松松地把你電動車給「順走」，不然打工怎麼會是他這輩子不可能的事情呢？牛逼之人，必有牛逼之處。
那在程式設計世界裡，「鎖」更是五花八門，多種多樣，每種鎖的加鎖開銷以及應用場景也可能會不同。
如何用好鎖，也是程式員的基本素養之一了。
高并發的場景下，如果選對了合适的鎖，則會大大提高系統的性能，否則性能會降低。
是以，知道各種鎖的開銷，以及應用場景是很有必要的。
接下來，就談一談常見的這幾種鎖：
正文
多線程通路共享資源的時候，避免不了資源競争而導緻資料錯亂的問題，是以我們通常為了解決這一問題，都會在通路共享資源之前加鎖。
最常用的就是互斥鎖，當然還有很多種不同的鎖，比如自旋鎖、讀寫鎖、樂觀鎖等，不同種類的鎖自然适用于不同的場景。
如果選擇了錯誤的鎖，那麼在一些高并發的場景下，可能會降低系統的性能，這樣使用者體驗就會非常差了。
是以，為了選擇合适的鎖，我們不僅需要清楚知道加鎖的成本開銷有多大，還需要分析業務場景中通路的共享資源的方式，再來還要考慮并發通路共享資源時的沖突機率。
對症下藥，才能減少鎖對高并發性能的影響。
那接下來，針對不同的應用場景，談一談「互斥鎖、自旋鎖、讀寫鎖、樂觀鎖、悲觀鎖」的選擇和使用。
互斥鎖與自旋鎖：誰更輕松自如？
最底層的兩種就是會「互斥鎖和自旋鎖」，有很多進階的鎖都是基于它們實作的，你可以認為它們是各種鎖的地基，是以我們必須清楚它倆之間的差別和應用。
加鎖的目的就是保證共享資源在任意時間裡，隻有一個線程通路，這樣就可以避免多線程導緻共享資料錯亂的問題。
當已經有一個線程加鎖後，其他線程加鎖則就會失敗，互斥鎖和自旋鎖對于加鎖失敗後的處理方式是不一樣的：
1.互斥鎖加鎖失敗後，線程會釋放CPU ，給其他線程；
2.自旋鎖加鎖失敗後，線程會忙等待，直到它拿到鎖；
互斥鎖是一種「獨占鎖」，比如當線程 A 加鎖成功後，此時互斥鎖已經被線程 A 獨占了，隻要線程 A 沒有釋放手中的鎖，線程 B 加鎖就會失敗，于是就會釋放 CPU 讓給其他線程，既然線程 B 釋放掉了 CPU，自然線程 B 加鎖的代碼就會被阻塞。
對于互斥鎖加鎖失敗而阻塞的現象，是由作業系統核心實作的。當加鎖失敗時，核心會将線程置為「睡眠」狀态，等到鎖被釋放後，核心會在合适的時機喚醒線程，當這個線程成功擷取到鎖後，于是就可以繼續執行。
如下圖：
當線程A進入鎖住的代碼段取到鎖進行業務執行，此時線程B進來發現需要執行的代碼段已經被鎖住，且無法擷取到鎖，則讓出CPU執行權，将機會給到其他的線程執行，此時，互斥鎖加鎖失敗，會從使用者态陷入到核心态，讓核心幫我們切換線程，雖然簡化了使用鎖的難度，但是存在一定的性能開銷成本。
那這個開銷成本是什麼呢？會有兩次線程上下文切換的成本：
- 當線程加鎖失敗時，核心會把線程的狀态從「運作」狀态設定為「睡眠」狀态，然後把 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 之間并行修改的地方就會發生沖突。
服務端要怎麼驗證是否沖突了呢？通常方案如下：
- 1.由于發生沖突的機率比較低，是以先讓使用者編輯文檔，但是浏覽器在下載下傳文檔時會記錄下服務端傳回的文檔版本号；
- 2.當使用者送出修改時，發給服務端的請求會帶上原始文檔版本号，伺服器收到後将它與目前版本号進行比較，如果版本号一緻則修改成功，否則送出失敗。
實際上，我們常見的 SVN 和 Git 也是用了樂觀鎖的思想，先讓使用者編輯代碼，然後送出的時候，通過版本号來判斷是否産生了沖突，發生了沖突的地方，需要我們自己修改後，再重新送出。
樂觀鎖雖然去除了加鎖解鎖的操作，但是一旦發生沖突，重試的成本非常高，是以隻有在沖突機率非常低，且加鎖成本非常高的場景時，才考慮使用樂觀鎖。
總結
開發過程中，最常見的就是互斥鎖的了，互斥鎖加鎖失敗時，會用「線程切換」來應對，當加鎖失敗的線程再次加鎖成功後的這一過程，會有兩次線程上下文切換的成本，性能損耗比較大。
如果我們明确知道被鎖住的代碼的執行時間很短，那我們應該選擇開銷比較小的自旋鎖，因為自旋鎖加鎖失敗時，并不會主動産生線程切換，而是一直忙等待，直到擷取到鎖，那麼如果被鎖住的代碼執行時間很短，那這個忙等待的時間相對應也很短。
如果能區分讀操作和寫操作的場景，那讀寫鎖就更合适了，它允許多個讀線程可以同時持有讀鎖，提高了讀的并發性。根據偏袒讀方還是寫方，可以分為讀優先鎖和寫優先鎖，讀優先鎖并發性很強，但是寫線程會被餓死，而寫優先鎖會優先服務寫線程，讀線程也可能會被餓死，那為了避免饑餓的問題，于是就有了公平讀寫鎖，它是用隊列把請求鎖的線程排隊，并保證先入先出的原則來對線程加鎖，這樣便保證了某種線程不會被餓死，通用性也更好點。
互斥鎖和自旋鎖都是最基本的鎖，讀寫鎖可以根據場景來選擇這兩種鎖其中的一個進行實作。
另外，互斥鎖、自旋鎖、讀寫鎖都屬于悲觀鎖，悲觀鎖認為并發通路共享資源時，沖突機率可能非常高，是以在通路共享資源前，都需要先加鎖。
相反的，如果并發通路共享資源時，沖突機率非常低的話，就可以使用樂觀鎖，它的工作方式是，在通路共享資源時，不用先加鎖，修改完共享資源後，再驗證這段時間内有沒有發生沖突，如果沒有其他線程在修改資源，那麼操作完成，如果發現有其他線程已經修改過這個資源，就放棄本次操作。
但是，一旦沖突機率上升，就不适合使用樂觀鎖了，因為它解決沖突的重試成本非常高。
不管使用的哪種鎖，我們的加鎖的代碼範圍應該盡可能的小，也就是加鎖的粒度要小，這樣執行速度會比較快。再來，使用上了合适的鎖，就會快上加快了。