深入JVM鎖機制1-synchronized
阿新 • • 發佈:2019-01-08
資料同步需要依賴鎖,那鎖的同步又依賴誰?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. 自旋鎖
- 如果平均負載小於CPUs則一直自旋
- 如果有超過(CPUs/2)個執行緒正在自旋,則後來執行緒直接阻塞
- 如果正在自旋的執行緒發現Owner發生了變化則延遲自旋時間(自旋計數)或進入阻塞
- 如果CPU處於節電模式則停止自旋
- 自旋時間的最壞情況是CPU的儲存延遲(CPU A儲存了一個數據,到CPU B得知這個資料直接的時間差)
- 自旋時會適當放棄執行緒優先順序之間的差異
3. 偏向鎖
在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一致性流量的例外情況:
NUMA(Non Uniform Memory Access Achitecture)架構: 與SMP對應還有非對稱多處理器架構,現在主要應用在一些高階處理器上,主要特點是沒有匯流排,沒有公用主存,每個Core有自己的記憶體,針對這種結構此處不做討論。