自旋鎖、偏向鎖、輕量級鎖、重量級鎖

重量級鎖

內置鎖在Java中被抽象爲監視器鎖（monitor）。在JDK 1.6之前，監視器鎖可以認爲直接對應底層操作系統中的互斥量（mutex）。這種同步方式的成本非常高，包括系統調用引起的內核態與用戶態切換、線程阻塞造成的線程切換等。因此，後來稱這種鎖爲“重量級鎖”。

自旋鎖

首先，內核態與用戶態的切換上不容易優化。但通過自旋鎖，可以減少線程阻塞造成的線程切換（包括掛起線程和恢復線程）。

如果鎖的粒度小，那麼鎖的持有時間比較短（儘管具體的持有時間無法得知，但可以認爲，通常有一部分鎖能滿足上述性質）。那麼，對於競爭這些鎖的而言，因爲鎖阻塞造成線程切換的時間與鎖持有的時間相當，減少線程阻塞造成的線程切換，能得到較大的性能提升。具體如下：

• 當前線程競爭鎖失敗時，打算阻塞自己
• 不直接阻塞自己，而是自旋（空等待，比如一個空的有限for循環）一會
• 在自旋的同時重新競爭鎖
• 如果自旋結束前獲得了鎖，那麼鎖獲取成功；否則，自旋結束後阻塞自己

如果在自旋的時間內，鎖就被舊owner釋放了，那麼當前線程就不需要阻塞自己（也不需要在未來鎖釋放時恢復），減少了一次線程切換。

“鎖的持有時間比較短”這一條件可以放寬。實際上，只要鎖競爭的時間比較短（比如線程1快釋放鎖的時候，線程2纔會來競爭鎖），就能夠提高自旋獲得鎖的概率。這通常發生在鎖持有時間長，但競爭不激烈的場景中。

缺點

• 單核處理器上，不存在實際的並行，當前線程不阻塞自己的話，舊owner就不能執行，鎖永遠不會釋放，此時不管自旋多久都是浪費；進而，如果線程多而處理器少，自旋也會造成不少無謂的浪費。
• 自旋鎖要佔用CPU，如果是計算密集型任務，這一優化通常得不償失，減少鎖的使用是更好的選擇。
• 如果鎖競爭的時間比較長，那麼自旋通常不能獲得鎖，白白浪費了自旋佔用的CPU時間。這通常發生在鎖持有時間長，且競爭激烈的場景中，此時應主動禁用自旋鎖。

使用-XX:-UseSpinning參數關閉自旋鎖優化；-XX:PreBlockSpin參數修改默認的自旋次數。

自適應自旋鎖

自適應意味着自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定：

• 如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，並且持有鎖的線程正在運行中，那麼虛擬機就會認爲這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間，比如100個循環。
• 相反的，如果對於某個鎖，自旋很少成功獲得過，那在以後要獲取這個鎖時將可能減少自旋時間甚至省略自旋過程，以避免浪費處理器資源。

自適應自旋解決的是“鎖競爭時間不確定”的問題。JVM很難感知到確切的鎖競爭時間，而交給用戶分析就違反了JVM的設計初衷。自適應自旋假定不同線程持有同一個鎖對象的時間基本相當，競爭程度趨於穩定，因此，可以根據上一次自旋的時間與結果調整下一次自旋的時間。

缺點

然而，自適應自旋也沒能徹底解決該問題，如果默認的自旋次數設置不合理（過高或過低），那麼自適應的過程將很難收斂到合適的值。

輕量級鎖

自旋鎖的目標是降低線程切換的成本。如果鎖競爭激烈，我們不得不依賴於重量級鎖，讓競爭失敗的線程阻塞；如果完全沒有實際的鎖競爭，那麼申請重量級鎖都是浪費的。輕量級鎖的目標是，減少無實際競爭情況下，使用重量級鎖產生的性能消耗，包括系統調用引起的內核態與用戶態切換、線程阻塞造成的線程切換等。

顧名思義，輕量級鎖是相對於重量級鎖而言的。使用輕量級鎖時，不需要申請互斥量，僅僅_將Mark Word中的部分字節CAS更新指向線程棧中的Lock Record，如果更新成功，則輕量級鎖獲取成功_，記錄鎖狀態爲輕量級鎖；否則，說明已經有線程獲得了輕量級鎖，目前發生了鎖競爭（不適合繼續使用輕量級鎖），接下來膨脹爲重量級鎖。

當然，由於輕量級鎖天然瞄準不存在鎖競爭的場景，如果存在鎖競爭但不激烈，仍然可以用自旋鎖優化，自旋失敗後再膨脹爲重量級鎖。

缺點

同自旋鎖相似：

• 如果鎖競爭激烈，那麼輕量級將很快膨脹爲重量級鎖，那麼維持輕量級鎖的過程就成了浪費。

偏向鎖

在沒有實際競爭的情況下，還能夠針對部分場景繼續優化。如果不僅僅沒有實際競爭，自始至終，使用鎖的線程都只有一個，那麼，維護輕量級鎖都是浪費的。偏向鎖的目標是，減少無競爭且只有一個線程使用鎖的情況下，使用輕量級鎖產生的性能消耗。輕量級鎖每次申請、釋放鎖都至少需要一次CAS，但偏向鎖只有初始化時需要一次CAS。

“偏向”的意思是，偏向鎖假定將來只有第一個申請鎖的線程會使用鎖（不會有任何線程再來申請鎖），因此，只需要在Mark Word中CAS記錄owner（本質上也是更新，但初始值爲空），如果記錄成功，則偏向鎖獲取成功，記錄鎖狀態爲偏向鎖，以後當前線程等於owner就可以零成本的直接獲得鎖；否則，說明有其他線程競爭，膨脹爲輕量級鎖。

偏向鎖無法使用自旋鎖優化，因爲一旦有其他線程申請鎖，就破壞了偏向鎖的假定。

缺點

同樣的，如果明顯存在其他線程申請鎖，那麼偏向鎖將很快膨脹爲輕量級鎖。

不過這個副作用已經小的多。

如果需要，使用參數-XX:-UseBiasedLocking禁止偏向鎖優化（默認打開）。

小結

鎖	優點	缺點	適用場景
偏向鎖	加鎖和解鎖不需要額外的消耗，和執行非同步方法比僅存在納秒級的差距	如果線程間存在鎖競爭，會帶來額外的鎖撤銷的消耗	適用於只有一個線程訪問同步塊場景
輕量級鎖	競爭的線程不會阻塞，提高了程序的響應速度	如果始終得不到鎖競爭的線程使用自旋會消耗CPU	追求響應時間,鎖佔用時間很短
重量級鎖	線程競爭不使用自旋，不會消耗CPU	線程阻塞，響應時間緩慢	追求吞吐量,鎖佔用時間較長

另外，如果鎖競爭時間短，可以使用自旋鎖進一步優化輕量級鎖、重量級鎖的性能，減少線程切換。

如果鎖競爭程度逐漸提高（緩慢），那麼從偏向鎖逐步膨脹到重量鎖，能夠提高系統的整體性能。

鎖分配和膨脹過程

前面講述了內置鎖在使用過程中的一些基本問題和解決方案，實現原理一筆帶過。詳細的鎖分配和膨脹過程如下：

 

 

 

圖中有一處疑問：

按照圖中流程，如果發現鎖已經膨脹爲重量級鎖，就直接使用互斥量mutex阻塞當前線程。

然而，自旋鎖的一大好處就是減少線程切換的開銷。在這裏沒有必要直接阻塞當前線程，大可以像輕量級鎖一樣，自旋一會，失敗了再阻塞。

特別說明兩點：

• CAS記錄owner時，expected == null，newValue == ownerThreadId，因此，只有第一個申請偏向鎖的線程能夠返回成功，後續線程都必然失敗（部分線程檢測到可偏向，同時嘗試CAS記錄owner）。
• 內置鎖只能沿着偏向鎖、輕量級鎖、重量級鎖的順序逐漸膨脹，不能“收縮”。這基於JVM的另一個假定，“一旦破壞了上一級鎖的假定，就認爲該假定以後也必不成立”。

另外，當重量級鎖被解除後，需要喚醒一個被阻塞的線程，這部分邏輯與ReentrantLock基本相同，詳見源碼|併發一枝花之ReentrantLock與AQS（1）：lock、unlock。

參考：

https://juejin.im/post/5a5c09d051882573282164ae
https://www.cnblogs.com/wade-luffy/p/5969418.html