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中引入了偏向鎖,偏向鎖主要解決無競爭下的鎖性能問題,首先我們看下無競爭下鎖存在什麼問題:
現在幾乎所有的鎖都是可重入的,也即已經獲得鎖的線程可以多次鎖住/解鎖監視對象,按照之前的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一致性流量的例外情況:
NUMA(Non Uniform Memory Access Achitecture)架構:
與SMP對應還有非對稱多處理器架構,現在主要應用在一些高端處理器上,主要特點是沒有總線,沒有公用主存,每個Core有自己的內存,針對這種結構此處不做討論。
3.2 偏向解除
偏向鎖引入的一個重要問題是,在多爭用的場景下,如果另外一個線程爭用偏向對象,擁有者需要釋放偏向鎖,而釋放的過程會帶來一些性能開銷,但總體說來偏向鎖帶來的好處還是大於CAS代價的。
4. 總結
關於鎖,JVM中還引入了一些其他技術比如鎖膨脹等,這些與自旋鎖、偏向鎖相比影響不是很大,這裏就不做介紹。
通過上面的介紹可以看出,synchronized的底層實現主要依靠Lock-Free的隊列,基本思路是自旋後阻塞,競爭切換後繼續競爭鎖,稍微犧牲了公平性,但獲得了高吞吐量。下面會繼續介紹JVM鎖中的Lock(深入JVM鎖
- Lock)。