前言
生活中用到的鎖，用途都比較簡單粗暴，上鎖基本是爲了防止外人進來、電動車被偷等等。程序員
但生活中也不是沒有 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 小時睡覺。
最後，固然看了「信條」，諾蘭用巨資拍攝出來的電影，花錢買飛機來撞，畫面很是震撼，能夠說很是有誠意了。諾蘭鍾愛時間的概念，此次則以時間倒流方式來呈現，很是的燒腦，反正我看完後腦殼懵懵的，我就是要這種感受，嘻嘻。
你們好，我是小林，一個專爲你們圖解的工具人，若是以爲文章對你有幫助，歡迎分享給你的朋友，咱們下次見！
推薦閱讀
本文分享自微信公衆號 - 小林coding（CodingLin）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。