java之synchronized的實現(xiàn)原理

目前在Java中存在兩種鎖機制：synchronized和Lock， Lock接口及其實現(xiàn)類是JDK5增加的內(nèi)容，其作者是大名鼎鼎的并發(fā)專家Doug Lea。本文并不比較synchronized與Lock孰優(yōu)孰劣，只是介紹二者的實現(xiàn)原理。

數(shù)據(jù)同步需要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟件層面依賴JVM，而Lock給出的方案是在硬件層面依賴特殊的CPU指令，大家可能會進一步追問：JVM底層又是如何實現(xiàn)synchronized的？

本文所指說的JVM是指Hotspot的6u23版本，下面首先介紹synchronized的實現(xiàn)：synrhronized關(guān)鍵字簡潔、清晰、語義明確，因此即使有了Lock接口，使用的還是非常廣泛。其應(yīng)用層的語義是可以把任何一個非null對象作為”鎖”， 當synchronized作用在方法上時，鎖住的便是對象實例（this）；當作用在靜態(tài)方法時鎖住的便是對象對應(yīng)的Class實例，因為Class數(shù)據(jù)存在于永久代，因此靜態(tài)方法鎖相當于該類的一個全局鎖；當synchronized作用于某一個對象實例時，鎖住的便是對應(yīng)的代碼塊。在HotSpot JVM實現(xiàn)中，鎖有個專門的名字：對象監(jiān)視器。

1、線程狀態(tài)及狀態(tài)轉(zhuǎn)換

當多個線程同時請求某個對象監(jiān)視器時，對象監(jiān)視器會設(shè)置幾種狀態(tài)用來區(qū)分請求的線程：

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

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

Wait Set：那些調(diào)用wait方法被阻塞的線程被放置到Wait Set

OnDeck：任何時刻最多只能有一個線程正在競爭鎖，該線程稱為OnDeck

Owner：獲得鎖的線程稱為Owner

!Owner：釋放鎖的線程

新請求鎖的線程將首先被加入到ConetentionList中，當某個擁有鎖的線程（Owner狀態(tài)）調(diào)用unlock之后，如果發(fā)現(xiàn)EntryList為空則從ContentionList中移動線程到EntryList， 下面說明下ContentionList和EntryList的實現(xiàn)方式：

1.1 ContentionList虛擬隊列

ContentionList并不是一個真正的Queue，而只是一個虛擬隊列，原因在于ContentionList是由Node及其next指針邏輯構(gòu)成，并不存在一個Queue的數(shù)據(jù)結(jié)構(gòu)。ContentionList是一個后進先出（LIFO）的隊列，每次新加入Node時都會在隊頭進行，通過CAS改變第一個節(jié)點的的指針為新增節(jié)點，同時設(shè)置新增節(jié)點的next指向后續(xù)節(jié)點，而取得操作則發(fā)生在隊尾。顯然，該結(jié)構(gòu)其實是個Lock-Free(無鎖)的隊列。

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

1.2 EntryList

EntryList與ContentionList邏輯上同屬等待隊列，ContentionList會被線程并發(fā)訪問，為了降低對ContentionList隊尾的爭用，而建立EntryList。 Owner線程在unlock時會從ContentionList中遷移線程到EntryList，并會指定EntryList中的某個線程（一般為Head）為Ready（OnDeck）線程。Owner線程并不是把鎖傳遞給OnDeck線程，只是把競爭鎖的權(quán)利交給OnDeck，OnDeck線程需要重新競爭鎖。這樣做雖然犧牲了一定的公平性，但極大的提高了整體吞吐量，在Hotspot中把OnDeck的選擇行為稱之為“競爭切換”。

OnDeck線程獲得鎖后即變?yōu)閛wner線程，無法獲得鎖則會依然留在EntryList中，考慮到公平性，在EntryList中的位置不發(fā)生變化（依然在隊頭）。如果Owner線程被wait方法阻塞，則轉(zhuǎn)移到WaitSet隊列；如果在某個時刻被notify/notifyAll喚醒，則再次轉(zhuǎn)移到EntryList。

2、自旋鎖

那些處于ContetionList、EntryList、WaitSet中的線程均處于阻塞狀態(tài)，阻塞操作由操作系統(tǒng)完成（在Linxu下通過pthread_mutex_lock函數(shù)）。線程被阻塞后便進入內(nèi)核（Linux）調(diào)度狀態(tài)，這個會導(dǎo)致系統(tǒng)在用戶態(tài)與內(nèi)核態(tài)之間來回切換，嚴重影響鎖的性能。

緩解上述問題的辦法便是自旋，其原理是：當發(fā)生爭用時，若Owner線程能在很短的時間內(nèi)釋放鎖， 則那些正在爭用線程可以稍微等一等（自旋），在Owner線程釋放鎖后，爭用線程可能會立即得到鎖，從而避免了系統(tǒng)阻塞。但Owner運行的時間可能會超出了臨界值，爭用線程自旋一段時間后還是無法獲得鎖，這時爭用線程則會停止自旋進入阻塞狀態(tài)（后退）?；舅悸肪褪亲孕怀晒υ僮枞?，盡量降低阻塞的可能性，這對那些執(zhí)行時間很短的代碼塊來說有非常重要的性能提高。 自旋鎖有個更貼切的名字：自旋-指數(shù)后退鎖，也即復(fù)合鎖。很顯然，自旋在多處理器上才有意義。

還有個問題是，線程自旋時做些啥？其實啥都不做，可以執(zhí)行幾次for循環(huán)，可以執(zhí)行幾條空的匯編指令，目的是占著CPU不放，等待獲取鎖的機會。所以說，自旋是把雙刃劍，如果旋的時間過長會影響整體性能，時間過短又達不到延遲阻塞的目的。顯然，自旋的周期選擇顯得非常重要，但這與操作系統(tǒng)、硬件體系、系統(tǒng)的負載等諸多場景相關(guān)，很難選擇，如果選擇不當，不但性能得不到提高，可能還會下降，因此大家普遍認為自旋鎖不具有擴展性。

對自旋鎖周期的選擇上，HotSpot認為最佳時間應(yīng)是一個線程上下文切換的時間，但目前并沒有做到。經(jīng)過調(diào)查，目前只是通過匯編暫停了幾個CPU周期，除了自旋周期選擇，HotSpot還進行許多其他的自旋優(yōu)化策略，具體如下：

* 如果平均負載小于CPUs則一直自旋

* 如果有超過(CPUs/2)個線程正在自旋，則后來線程直接阻塞

* 如果正在自旋的線程發(fā)現(xiàn)Owner發(fā)生了變化則延遲自旋時間（自旋計數(shù)）或進入阻塞

* 如果CPU處于節(jié)電模式則停止自旋

* 自旋時間的最壞情況是CPU的存儲延遲（CPU A存儲了一個數(shù)據(jù)，到CPU B得知這個數(shù)據(jù)直接的時間差）

* 自旋時會適當放棄線程優(yōu)先級之間的差異

那synchronized實現(xiàn)何時使用了自旋鎖？ 答案是在線程進入ContentionList時，也即第一步操作前。線程在進入等待隊列時首先進行自旋嘗試獲得鎖，如果不成功再進入等待隊列。這對那些已經(jīng)在等待隊列中的線程來說，稍微顯得不公平。還有一個不公平的地方是自旋線程可能會搶占了Ready線程的鎖。自旋鎖由每個監(jiān)視對象維護，每個監(jiān)視對象一個。

3、偏向鎖

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

現(xiàn)在幾乎所有的鎖都是可重入的，也即已經(jīng)獲得鎖的線程可以多次鎖住/解鎖監(jiān)視對象，按照之前的HotSpot設(shè)計，每次加鎖/解鎖都會涉及到一些CAS操作（比如對等待隊列的CAS操作），CAS操作會延遲本地調(diào)用，因此偏向鎖的想法是一旦線程第一次獲得了監(jiān)視對象，之后讓監(jiān)視對象“偏向”這個線程，之后的多次調(diào)用則可以避免CAS操作，說白了就是置個變量，如果發(fā)現(xiàn)為true則無需再走各種加鎖/解鎖流程。 但還有很多概念需要解釋、很多引入的問題需要解決：

3.1 CAS及SMP架構(gòu)

CAS為什么會引入本地延遲？這要從SMP（對稱多處理器）架構(gòu)說起

其意思是所有的CPU會共享一條系統(tǒng)總線（BUS），靠此總線連接主存。每個核都有自己的一級緩存，各核相對于BUS對稱分布，因此這種結(jié)構(gòu)稱為“對稱多處理器”。

而CAS的全稱為Compare-And-Swap，是一條CPU的原子指令，其作用是讓CPU比較后原子地更新某個位置的值，經(jīng)過調(diào)查發(fā)現(xiàn)，其實現(xiàn)方式是基于硬件平臺的匯編指令，就是說CAS是靠硬件實現(xiàn)的，JVM只是封裝了匯編調(diào)用，那些AtomicInteger類便是使用了這些封裝后的接口。

Core1和Core2可能會同時把主存中某個位置的值Load到自己的L1 Cache中，當Core1在自己的L1 Cache中修改這個位置的值時，會通過總線，使Core2中L1 Cache對應(yīng)的值“失效”，而Core2一旦發(fā)現(xiàn)自己L1 Cache中的值失效（稱為Cache命中缺失）則會通過總線從內(nèi)存中加載該地址最新的值，大家通過總線的來回通信稱為“Cache一致性流量”，因為總線被設(shè)計為固定的“通信能力”，如果Cache一致性流量過大，總線將成為瓶頸。而當Core1和Core2中的值再次一致時，稱為“Cache一致性”，從這個層面來說，鎖設(shè)計的終極目標便是減少Cache一致性流量。

而CAS恰好會導(dǎo)致Cache一致性流量，如果有很多線程都共享同一個對象，當某個Core CAS成功時必然會引起總線風(fēng)暴，這就是所謂的本地延遲，本質(zhì)上偏向鎖就是為了消除CAS，降低Cache一致性流量。

3.2 偏向解除

偏向鎖引入的一個重要問題是，在多爭用的場景下，如果另外一個線程爭用偏向?qū)ο?，擁有者需要釋放偏向鎖，而釋放的過程會帶來一些性能開銷，但總體說來偏向鎖帶來的好處還是大于CAS代價的。

4、總結(jié)

關(guān)于鎖，JVM中還引入了一些其他技術(shù)比如鎖膨脹等，這些與自旋鎖、偏向鎖相比影響不是很大，這里就不做介紹。

通過上面的介紹可以看出，synchronized的底層實現(xiàn)主要依靠Lock-Free的隊列，基本思路是自旋后阻塞，競爭切換后繼續(xù)競爭鎖，稍微犧牲了公平性，但獲得了高吞吐量。

本文版權(quán)歸黑馬程序員JavaEE學(xué)院所有，歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明作者出處。謝謝！

作者：黑馬程序員JavaEE培訓(xùn)學(xué)院

首發(fā)：http://java.itheima.com/