轉：JVM底層又是如何實現synchronized的

目前在Java中存在兩種鎖機制：synchronized和Lock，Lock接口及其實現類是JDK5增長的內容，其做者是大名鼎鼎的併發專家Doug Lea。本文並不比較synchronized與Lock孰優孰劣，只是介紹兩者的實現原理。

數據同步須要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟件層面依賴JVM，而Lock給出的方案是在硬件層面依賴特殊的CPU指令，你們可能會進一步追問：JVM底層又是如何實現synchronized的？

本文所指說的JVM是指Hotspot的6u23版本，下面首先介紹synchronized的實現：

synrhronized關鍵字簡潔、清晰、語義明確，所以即便有了Lock接口，使用的仍是很是普遍。其應用層的語義是能夠把任何一個非null對象 做爲"鎖"，當synchronized做用在方法上時，鎖住的即是對象實例（this）；看成用在靜態方法時鎖住的即是對象對應的Class實例，由於 Class數據存在於永久帶，所以靜態方法鎖至關於該類的一個全局鎖；當synchronized做用於某一個對象實例時，鎖住的即是對應的代碼塊。在 HotSpot JVM實現中，鎖有個專門的名字：對象監視器。 

1. 線程狀態及狀態轉換

當多個線程同時請求某個對象監視器時，對象監視器會設置幾種狀態用來區分請求的線程：

Contention List：全部請求鎖的線程將被首先放置到該競爭隊列

Entry List：Contention List中那些有資格成爲候選人的線程被移到Entry List

Wait Set：那些調用wait方法被阻塞的線程被放置到Wait Set

OnDeck：任什麼時候刻最多隻能有一個線程正在競爭鎖，該線程稱爲OnDeck

Owner：得到鎖的線程稱爲Owner

!Owner：釋放鎖的線程

下圖反映了個狀態轉換關係：

新請求鎖的線程將首先被加入到ConetentionList中，當某個擁有鎖的線程（Owner狀態）調用unlock以後，若是發現 EntryList爲空則從ContentionList中移動線程到EntryList，下面說明下ContentionList和EntryList 的實現方式：

1.1 ContentionList 虛擬隊列

ContentionList並非一個真正的Queue，而只是一個虛擬隊列，緣由在於ContentionList是由Node及其next指 針邏輯構成，並不存在一個Queue的數據結構。ContentionList是一個後進先出（LIFO）的隊列，每次新加入Node時都會在隊頭進行， 經過CAS改變第一個節點的的指針爲新增節點，同時設置新增節點的next指向後續節點，而取得操做則發生在隊尾。顯然，該結構實際上是個Lock- Free的隊列。

由於只有Owner線程才能從隊尾取元素，也即線程出列操做無爭用，固然也就避免了CAS的ABA問題。

1.2 EntryList

EntryList與ContentionList邏輯上同屬等待隊列，ContentionList會被線程併發訪問，爲了下降對 ContentionList隊尾的爭用，而創建EntryList。Owner線程在unlock時會從ContentionList中遷移線程到 EntryList，並會指定EntryList中的某個線程（通常爲Head）爲Ready（OnDeck）線程。Owner線程並非把鎖傳遞給 OnDeck線程，只是把競爭鎖的權利交給OnDeck，OnDeck線程須要從新競爭鎖。這樣作雖然犧牲了必定的公平性，但極大的提升了總體吞吐量，在 Hotspot中把OnDeck的選擇行爲稱之爲「競爭切換」。

OnDeck線程得到鎖後即變爲owner線程，沒法得到鎖則會依然留在EntryList中，考慮到公平性，在EntryList中的位置不 發生變化（依然在隊頭）。若是Owner線程被wait方法阻塞，則轉移到WaitSet隊列；若是在某個時刻被notify/notifyAll喚醒， 則再次轉移到EntryList。

2. 自旋鎖

那些處於ContetionList、EntryList、WaitSet中的線程均處於阻塞狀態，阻塞操做由操做系統完成（在Linxu下通 過pthread_mutex_lock函數）。線程被阻塞後便進入內核（Linux）調度狀態，這個會致使系統在用戶態與內核態之間來回切換，嚴重影響鎖的性能

緩解上述問題的辦法即是自旋，其原理是：當發生爭用時，若Owner線程能在很短的時間內釋放鎖，則那些正在爭用線程能夠稍微等一等（自旋）， 在Owner線程釋放鎖後，爭用線程可能會當即獲得鎖，從而避免了系統阻塞。但Owner運行的時間可能會超出了臨界值，爭用線程自旋一段時間後仍是沒法得到鎖，這時爭用線程則會中止自旋進入阻塞狀態（後退）。基本思路就是自旋，不成功再阻塞，儘可能下降阻塞的可能性，這對那些執行時間很短的代碼塊來講有非 常重要的性能提升。自旋鎖有個更貼切的名字：自旋-指數後退鎖，也即複合鎖。很顯然，自旋在多處理器上纔有意義。

還有個問題是，線程自旋時作些啥？其實啥都不作，能夠執行幾回for循環，能夠執行幾條空的彙編指令，目的是佔着CPU不放，等待獲取鎖的機 會。因此說，自旋是把雙刃劍，若是旋的時間過長會影響總體性能，時間太短又達不到延遲阻塞的目的。顯然，自旋的週期選擇顯得很是重要，但這與操做系統、硬件體系、系統的負載等諸多場景相關，很難選擇，若是選擇不當，不但性能得不到提升，可能還會降低，所以你們廣泛認爲自旋鎖不具備擴展性。

自旋優化策略

對自旋鎖週期的選擇上，HotSpot認爲最佳時間應是一個線程上下文切換的時間，但目前並無作到。通過調查，目前只是經過彙編暫停了幾個CPU週期，除了自旋週期選擇，HotSpot還進行許多其餘的自旋優化策略，具體以下：

若是平均負載小於CPUs則一直自旋

若是有超過(CPUs/2)個線程正在自旋，則後來線程直接阻塞

若是正在自旋的線程發現Owner發生了變化則延遲自旋時間（自旋計數）或進入阻塞

若是CPU處於節電模式則中止自旋

自旋時間的最壞狀況是CPU的存儲延遲（CPU A存儲了一個數據，到CPU B得知這個數據直接的時間差）

自旋時會適當放棄線程優先級之間的差別

那synchronized實現什麼時候使用了自旋鎖？答案是在線程進入ContentionList時，也即第一步操做前。線程在進入等待隊列時 首先進行自旋嘗試得到鎖，若是不成功再進入等待隊列。這對那些已經在等待隊列中的線程來講，稍微顯得不公平。還有一個不公平的地方是自旋線程可能會搶佔了 Ready線程的鎖。自旋鎖由每一個監視對象維護，每一個監視對象一個。

3. JVM1.6偏向鎖

在JVM1.6中引入了偏向鎖，偏向鎖主要解決無競爭下的鎖性能問題，首先咱們看下無競爭下鎖存在什麼問題：

如今幾乎全部的鎖都是可重入的，也即已經得到鎖的線程能夠屢次鎖住/解鎖監視對象，按照以前的HotSpot設計，每次加鎖/解鎖都會涉及到一些CAS操做（好比對等待隊列的CAS操做），CAS操做會延遲本地調用，所以偏向鎖的想法是一旦線程第一次得到了監視對象，以後讓監視對象「偏向」這個 線程，以後的屢次調用則能夠避免CAS操做，說白了就是置個變量，若是發現爲true則無需再走各類加鎖/解鎖流程。但還有不少概念須要解釋、不少引入的問題須要解決：

3.1 CAS及SMP架構

CAS爲何會引入本地延遲？這要從SMP（對稱多處理器）架構提及，下圖大概代表了SMP的結構：

其意思是全部的CPU會共享一條系統總線（BUS），靠此總線鏈接主存。每一個核都有本身的一級緩存，各核相對於BUS對稱分佈，所以這種結構稱爲「對稱多處理器」。

而CAS的全稱爲Compare-And-Swap，是一條CPU的原子指令，其做用是讓CPU比較後原子地更新某個位置的值，通過調查發現， 其實現方式是基於硬件平臺的彙編指令，就是說CAS是靠硬件實現的，JVM只是封裝了彙編調用，那些AtomicInteger類即是使用了這些封裝後的接口。

Core1和Core2可能會同時把主存中某個位置的值Load到本身的L1 Cache中，當Core1在本身的L1 Cache中修改這個位置的值時，會經過總線，使Core2中L1 Cache對應的值「失效」，而Core2一旦發現本身L1 Cache中的值失效（稱爲Cache命中缺失）則會經過總線從內存中加載該地址最新的值，你們經過總線的來回通訊稱爲「Cache一致性流量」，由於總 線被設計爲固定的「通訊能力」，若是Cache一致性流量過大，總線將成爲瓶頸。而當Core1和Core2中的值再次一致時，稱爲「Cache一致 性」，從這個層面來講，鎖設計的終極目標即是減小Cache一致性流量。

而CAS剛好會致使Cache一致性流量，若是有不少線程都共享同一個對象，當某個Core CAS成功時必然會引發總線風暴，這就是所謂的本地延遲，本質上偏向鎖就是爲了消除CAS，下降Cache一致性流量。

Cache一致性：

上面提到Cache一致性，實際上是有協議支持的，如今通用的協議是MESI（最先由Intel開始支持），具體參考：http://en.wikipedia.org/wiki/MESI_protocol，之後會仔細講解這部分。

Cache一致性流量的例外狀況：

其實也不是全部的CAS都會致使總線風暴，這跟Cache一致性協議有關，具體參考：http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot

NUMA(Non Uniform Memory Access Achitecture）架構：

與SMP對應還有非對稱多處理器架構，如今主要應用在一些高端處理器上，主要特色是沒有總線，沒有公用主存，每一個Core有本身的內存，針對這種結構此處不作討論。

3.2 偏向解除

偏向鎖引入的一個重要問題是，在多爭用的場景下，若是另一個線程爭用偏向對象，擁有者須要釋放偏向鎖，而釋放的過程會帶來一些性能開銷，但整體說來偏向鎖帶來的好處仍是大於CAS代價的。

4. 總結

關於鎖，JVM中還引入了一些其餘技術好比鎖膨脹等，這些與自旋鎖、偏向鎖相比影響不是很大，這裏就不作介紹。

經過上面的介紹能夠看出，synchronized的底層實現主要依靠Lock-Free的隊列，基本思路是自旋後阻塞，競爭切換後繼續競爭鎖，稍微犧牲了公平性，但得到了高吞吐量。

--------------------------------------------------------------------------

最近特喜歡看這樣刨根問底的文章，這篇文章原文還有一半是講Lock實現的原理的。原文的格式太差了，看都不想看，索性發上來，在這裏排版了看。寫底層確實沒有寫界面來的那麼容易出效果，須要慢慢慢慢的熬出來。