最底層的兩種就是會「互斥鎖和自旋鎖」，有很多高階的鎖都是基於它們實現的，你可以認為它們是各種鎖的地基，所以我們必須清楚它倆之間的區別和應用。
加鎖的目的就是保證共享資源在任意時間裡，只有乙個執行緒訪問，這樣就可以避免多執行緒導致共享資料錯亂的問題。
當已經有乙個執行緒加鎖後，其他執行緒加鎖則就會失敗，互斥鎖和自旋鎖對於加鎖失敗後的處理方式是不一樣的：
互斥鎖加鎖失敗後，執行緒會釋放 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 之間並行修改的地方就會發生衝突。
服務端要怎麼驗證是否衝突了呢？通常方案如下：
樂觀鎖雖然去除了加鎖解鎖的操作，但是一旦發生衝突，重試的成本非常高，所以只有在衝突概率非常低，且加鎖成本非常高的場景時，才考慮使用樂觀鎖。
開發過程中，最常見的就是互斥鎖的了，互斥鎖加鎖失敗時，會用「執行緒切換」來應對，當加鎖失敗的執行緒再次加鎖成功後的這一過程，會有兩次執行緒上下文切換的成本，效能損耗比較大。
如果我們明確知道被鎖住的**的執行時間很短，那我們應該選擇開銷比較小的自旋鎖，因為自旋鎖加鎖失敗時，並不會主動產生執行緒切換，而是一直忙等待，直到獲取到鎖，那麼如果被鎖住的**執行時間很短，那這個忙等待的時間相對應也很短。
如果能區分讀操作和寫操作的場景，那讀寫鎖就更合適了，它允許多個讀執行緒可以同時持有讀鎖，提高了讀的併發性。根據偏袒讀方還是寫方，可以分為讀優先鎖和寫優先鎖，讀優先鎖併發性很強，但是寫執行緒會被餓死，而寫優先鎖會優先服務寫執行緒，讀執行緒也可能會被餓死，那為了避免飢餓的問題，於是就有了公平讀寫鎖，它是用佇列把請求鎖的執行緒排隊，並保證先入先出的原則來對執行緒加鎖，這樣便保證了某種執行緒不會被餓死，通用性也更好點。
互斥鎖和自旋鎖都是最基本的鎖，讀寫鎖可以根據場景來選擇這兩種鎖其中的乙個進行實現。
另外，互斥鎖、自旋鎖、讀寫鎖都屬於悲觀鎖，悲觀鎖認為併發訪問共享資源時，衝突概率可能非常高，所以在訪問共享資源前，都需要先加鎖。
相反的，如果併發訪問共享資源時，衝突概率非常低的話，就可以使用樂觀鎖，它的工作方式是，在訪問共享資源時，不用先加鎖，修改完共享資源後，再驗證這段時間內有沒有發生衝突，如果沒有其他執行緒在修改資源，那麼操作完成，如果發現有其他執行緒已經修改過這個資源，就放棄本次操作。
但是，一旦衝突概率上公升，就不適合使用樂觀鎖了，因為它解決衝突的重試成本非常高。
不管使用的哪種鎖，我們的加鎖的**範圍應該盡可能的小，也就是加鎖的粒度要小，這樣執行速度會比較快。再來，使用上了合適的鎖，就會快上加快了。
作業系統 互斥鎖 自旋鎖 讀寫鎖 悲觀鎖 樂觀鎖
使用場景 如果你能確定被鎖住的 執行時間很長，就不應該用互斥鎖 加鎖的目的就是保證共享資源在任意時間裡，只有乙個執行緒訪問，這樣就可以避免多執行緒導致共享資料錯亂的問題。互斥鎖加鎖失敗後，執行緒會釋放 cpu 給其他執行緒，自身處於獲取鎖阻塞狀態，然後從使用者態切換到核心態由由核心幫助進行切換執行緒...
樂觀鎖 悲觀鎖 自旋鎖
三 樂觀鎖和悲觀鎖的使用場景 四 自旋鎖 總是假設最壞的情況，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會阻塞直到它拿到鎖 共享資源每次只給乙個執行緒使用，其它執行緒阻塞，用完後再把資源轉讓給其它執行緒 傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比...
樂觀鎖 悲觀鎖 讀寫鎖 互斥鎖之間的關係
同一維度的概念，都是從資料訪問的角度來說。所以經常出現在資料庫相關問題中 即當資料同時被多個物件訪問了，應該持什麼態度來對資料進行保護 悲觀鎖認為，資料被訪問，對方很可能要修改這個資料。所以在此思想的引導下，資料被訪問時，不管是讀還是寫，步步加鎖。嚴格排斥其他物件的訪問。樂觀鎖認為，資料被訪問，對方...