啃碎併發（七）：深入分析Synchronized原理
前言
記得開始學習Java的時候，一遇到多執行緒情況就使用synchronized，相對於當時的我們來說synchronized是這麼的神奇而又強大，那個時候我們賦予它一個名字“同步”，也成為了我們解決多執行緒情況的百試不爽的良藥。但是，隨著學習的進行我們知道在JDK1.5之前synchronized是一個重量級鎖，相對於j.u.c.Lock，它會顯得那麼笨重，以至於我們認為它不是那麼的高效而慢慢摒棄它。
不過，隨著Javs SE 1.6對synchronized進行的各種優化後，synchronized並不會顯得那麼重了。下面來一起探索synchronized的基本使用、實現機制、Java是如何對它進行了優化、鎖優化機制、鎖的儲存結構等升級過程。
1 基本使用
Synchronized是Java中解決併發問題的一種最常用的方法，也是最簡單的一種方法。Synchronized的作用主要有三個：
從語法上講，Synchronized可以把任何一個非null物件作為"鎖"，在HotSpot JVM實現中，鎖有個專門的名字：物件監視器（Object Monitor）。
Synchronized總共有三種用法：
注意，synchronized 內建鎖 是一種物件鎖（鎖的是物件而非引用變數），作用粒度是物件，可以用來實現對臨界資源的同步互斥訪問，是 可重入 的。其可重入最大的作用是避免死鎖，如：
2 同步原理
資料同步需要依賴鎖，那鎖的同步又依賴誰？synchronized給出的答案是在軟體層面依賴JVM，而j.u.c.Lock給出的答案是在硬體層面依賴特殊的CPU指令。
當一個執行緒訪問同步程式碼塊時，首先是需要得到鎖才能執行同步程式碼，當退出或者丟擲異常時必須要釋放鎖，那麼它是如何來實現這個機制的呢？我們先看一段簡單的程式碼：
檢視反編譯後結果：
反編譯結果
1.monitorenter：每個物件都是一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，執行緒執行monitorenter指令時嘗試獲取monitor的所有權，過程如下：
通過上面兩段描述，我們應該能很清楚的看出Synchronized的實現原理，Synchronized的語義底層是通過一個monitor的物件來完成，其實wait/notify等方法也依賴於monitor物件，這就是為什麼只有在同步的塊或者方法中才能呼叫wait/notify等方法，否則會丟擲java.lang.IllegalMonitorStateException的異常的原因。
再來看一下同步方法：
檢視反編譯後結果：
反編譯結果
從編譯的結果來看，方法的同步並沒有通過指令
monitorenter和monitorexit來完成（理論上其實也可以通過這兩條指令來實現），不過相對於普通方法，其常量池中多了ACC_SYNCHRONIZED標示符。JVM就是根據該標示符來實現方法的同步的：
兩種同步方式本質上沒有區別，只是方法的同步是一種隱式的方式來實現，無需通過位元組碼來完成。兩個指令的執行是JVM通過呼叫作業系統的互斥原語mutex來實現，被阻塞的執行緒會被掛起、等待重新排程，會導致“使用者態和核心態”兩個態之間來回切換，對效能有較大影響。
3 同步概念
3.1 Java物件頭
在JVM中，物件在記憶體中的佈局分為三塊區域：物件頭、例項資料和對齊填充。如下圖所示：
Synchronized用的鎖就是存在Java物件頭裡的，那麼什麼是Java物件頭呢？Hotspot虛擬機器的物件頭主要包括兩部分資料：Mark Word（標記欄位）、Class Pointer（型別指標）。其中Class Pointer是物件指向它的類元資料的指標，虛擬機器通過這個指標來確定這個物件是哪個類的例項，Mark Word用於儲存物件自身的執行時資料，它是實現輕量級鎖和偏向鎖的關鍵。 Java物件頭具體結構描述如下：
Java物件頭結構組成 Mark Word用於儲存物件自身的執行時資料，如：雜湊碼（HashCode）、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒 ID、偏向時間戳等。下圖是Java物件頭無鎖狀態下Mark Word部分的儲存結構（32位虛擬機器）： Mark Word儲存結構 物件頭資訊是與物件自身定義的資料無關的額外儲存成本，但是考慮到虛擬機器的空間效率，Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲存儘量多的資料，它會根據物件的狀態複用自己的儲存空間，也就是說，Mark Word會隨著程式的執行發生變化，可能變化為儲存以下4種資料：Mark Word可能儲存4種資料
在64位虛擬機器下，Mark Word是64bit大小的，其儲存結構如下：
64位Mark Word儲存結構物件頭的最後兩位儲存了鎖的標誌位，01是初始狀態，未加鎖，其物件頭裡儲存的是物件本身的雜湊碼，隨著鎖級別的不同，物件頭裡會儲存不同的內容。偏向鎖儲存的是當前佔用此物件的執行緒ID；而輕量級則儲存指向執行緒棧中鎖記錄的指標。從這裡我們可以看到，“鎖”這個東西，可能是個鎖記錄+物件頭裡的引用指標（判斷執行緒是否擁有鎖時將執行緒的鎖記錄地址和物件頭裡的指標地址比較)，也可能是物件頭裡的執行緒ID（判斷執行緒是否擁有鎖時將執行緒的ID和物件頭裡儲存的執行緒ID比較）。
HotSpot虛擬機器物件頭Mark Word
3.2 物件頭中Mark Word與執行緒中Lock Record
線上程進入同步程式碼塊的時候，如果此同步物件沒有被鎖定，即它的鎖標誌位是01，則虛擬機器首先在當前執行緒的棧中建立我們稱之為“鎖記錄（Lock Record）”的空間，用於儲存鎖物件的Mark Word的拷貝，官方把這個拷貝稱為Displaced Mark Word。整個Mark Word及其拷貝至關重要。
Lock Record是執行緒私有的資料結構，每一個執行緒都有一個可用Lock Record列表，同時還有一個全域性的可用列表。每一個被鎖住的物件Mark Word都會和一個Lock Record關聯（物件頭的MarkWord中的Lock Word指向Lock Record的起始地址），同時Lock Record中有一個Owner欄位存放擁有該鎖的執行緒的唯一標識（或者object mark word），表示該鎖被這個執行緒佔用。如下圖所示為Lock Record的內部結構：
3.3 監視器（Monitor）
任何一個物件都有一個Monitor與之關聯，當且一個Monitor被持有後，它將處於鎖定狀態。Synchronized在JVM裡的實現都是基於進入和退出Monitor物件來實現方法同步和程式碼塊同步，雖然具體實現細節不一樣，但是都可以通過成對的MonitorEnter和MonitorExit指令來實現。
那什麼是Monitor？可以把它理解為一個同步工具，也可以描述為一種同步機制，它通常被描述為一個物件。
與一切皆物件一樣，所有的Java物件是天生的Monitor，每一個Java物件都有成為Monitor的潛質，因為在Java的設計中 ，每一個Java物件自打孃胎裡出來就帶了一把看不見的鎖，它叫做內部鎖或者Monitor鎖。
也就是通常說Synchronized的物件鎖，MarkWord鎖標識位為10，其中指標指向的是Monitor物件的起始地址。在Java虛擬機器（HotSpot）中，Monitor是由ObjectMonitor實現的，其主要資料結構如下（位於HotSpot虛擬機器原始碼ObjectMonitor.hpp檔案，C++實現的）：
ObjectMonitor中有兩個佇列，_WaitSet 和 _EntryList，用來儲存ObjectWaiter物件列表（每個等待鎖的執行緒都會被封裝成ObjectWaiter物件），_owner指向持有ObjectMonitor物件的執行緒，當多個執行緒同時訪問一段同步程式碼時：
同時，Monitor物件存在於每個Java物件的物件頭Mark Word中（儲存的指標的指向），Synchronized鎖便是通過這種方式獲取鎖的，也是為什麼Java中任意物件可以作為鎖的原因，同時notify/notifyAll/wait等方法會使用到Monitor鎖物件，所以必須在同步程式碼塊中使用。
監視器Monitor有兩種同步方式：互斥與協作。多執行緒環境下執行緒之間如果需要共享資料，需要解決互斥訪問資料的問題，監視器可以確保監視器上的資料在同一時刻只會有一個執行緒在訪問。
什麼時候需要協作？比如：
如上圖所示，一個執行緒通過1號門進入Entry Set(入口區)，如果在入口區沒有執行緒等待，那麼這個執行緒就會獲取監視器成為監視器的Owner，然後執行監視區域的程式碼。如果在入口區中有其它執行緒在等待，那麼新來的執行緒也會和這些執行緒一起等待。執行緒在持有監視器的過程中，有兩個選擇，一個是正常執行監視器區域的程式碼，釋放監視器，通過5號門退出監視器；還有可能等待某個條件的出現，於是它會通過3號門到Wait Set（等待區）休息，直到相應的條件滿足後再通過4號門進入重新獲取監視器再執行。
注意：
4 鎖的優化
從JDK5引入了現代作業系統新增加的CAS原子操作（JDK5中並沒有對synchronized關鍵字做優化，而是體現在J.U.C中，所以在該版本concurrent包有更好的效能），從JDK6開始，就對synchronized的實現機制進行了較大調整，包括使用JDK5引進的CAS自旋之外，還增加了自適應的CAS自旋、鎖消除、鎖粗化、偏向鎖、輕量級鎖這些優化策略。由於此關鍵字的優化使得效能極大提高，同時語義清晰、操作簡單、無需手動關閉，所以推薦在允許的情況下儘量使用此關鍵字，同時在效能上此關鍵字還有優化的空間。
鎖主要存在四種狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖。但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級。
4.1 自旋鎖
執行緒的阻塞和喚醒需要CPU從使用者態轉為核心態，頻繁的阻塞和喚醒對CPU來說是一件負擔很重的工作，勢必會給系統的併發效能帶來很大的壓力。同時我們發現在許多應用上面，物件鎖的鎖狀態只會持續很短一段時間，為了這一段很短的時間頻繁地阻塞和喚醒執行緒是非常不值得的。
所以引入自旋鎖，何謂自旋鎖？
自旋鎖適用於鎖保護的臨界區很小的情況，臨界區很小的話，鎖佔用的時間就很短。自旋等待不能替代阻塞，雖然它可以避免執行緒切換帶來的開銷，但是它佔用了CPU處理器的時間。如果持有鎖的執行緒很快就釋放了鎖，那麼自旋的效率就非常好，反之，自旋的執行緒就會白白消耗掉處理的資源，它不會做任何有意義的工作，典型的佔著茅坑不拉屎，這樣反而會帶來效能上的浪費。所以說，自旋等待的時間（自旋的次數）必須要有一個限度，如果自旋超過了定義的時間仍然沒有獲取到鎖，則應該被掛起。
自旋鎖在JDK 1.4.2中引入，預設關閉，但是可以使用-XX:+UseSpinning開開啟，在JDK1.6中預設開啟。同時自旋的預設次數為10次，可以通過引數-XX:PreBlockSpin來調整。
如果通過引數-XX:PreBlockSpin來調整自旋鎖的自旋次數，會帶來諸多不便。假如將引數調整為10，但是系統很多執行緒都是等你剛剛退出的時候就釋放了鎖（假如多自旋一兩次就可以獲取鎖），是不是很尷尬。於是JDK1.6引入自適應的自旋鎖，讓虛擬機器會變得越來越聰明。
4.2 適應性自旋鎖
JDK 1.6引入了更加聰明的自旋鎖，即自適應自旋鎖。所謂自適應就意味著自旋的次數不再是固定的，它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。那它如何進行適應性自旋呢？
有了自適應自旋鎖，隨著程式執行和效能監控資訊的不斷完善，虛擬機器對程式鎖的狀況預測會越來越準確，虛擬機器會變得越來越聰明。
4.3 鎖消除
為了保證資料的完整性，在進行操作時需要對這部分操作進行同步控制，但是在有些情況下，JVM檢測到不可能存在共享資料競爭，這是JVM會對這些同步鎖進行鎖消除。
如果不存在競爭，為什麼還需要加鎖呢？所以鎖消除可以節省毫無意義的請求鎖的時間。變數是否逃逸，對於虛擬機器來說需要使用資料流分析來確定，但是對於程式設計師來說這還不清楚麼？在明明知道不存在資料競爭的程式碼塊前加上同步嗎？但是有時候程式並不是我們所想的那樣？雖然沒有顯示使用鎖，但是在使用一些JDK的內建API時，如StringBuffer、Vector、HashTable等，這個時候會存在隱形的加鎖操作。比如StringBuffer的append()方法，Vector的add()方法：
在執行這段程式碼時，JVM可以明顯檢測到變數vector沒有逃逸出方法vectorTest()之外，所以JVM可以大膽地將vector內部的加鎖操作消除。
4.4 鎖粗化
在使用同步鎖的時候，需要讓同步塊的作用範圍儘可能小—僅在共享資料的實際作用域中才進行同步，這樣做的目的是為了使需要同步的運算元量儘可能縮小，如果存在鎖競爭，那麼等待鎖的執行緒也能儘快拿到鎖。
在大多數的情況下，上述觀點是正確的。但是如果一系列的連續加鎖解鎖操作，可能會導致不必要的效能損耗，所以引入鎖粗話的概念。
如上面例項：4.5 偏向鎖
偏向鎖是JDK6中的重要引進，因為HotSpot作者經過研究實踐發現，在大多數情況下，鎖不僅不存在多執行緒競爭，而且總是由同一執行緒多次獲得，為了讓執行緒獲得鎖的代價更低，引進了偏向鎖。
偏向鎖是在單執行緒執行程式碼塊時使用的機制，如果在多執行緒併發的環境下（即執行緒A尚未執行完同步程式碼塊，執行緒B發起了申請鎖的申請），則一定會轉化為輕量級鎖或者重量級鎖。
在JDK5中偏向鎖預設是關閉的，而到了JDK6中偏向鎖已經預設開啟。如果併發數較大同時同步程式碼塊執行時間較長，則被多個執行緒同時訪問的概率就很大，就可以使用引數-XX:-UseBiasedLocking來禁止偏向鎖(但這是個JVM引數，不能針對某個物件鎖來單獨設定)。
引入偏向鎖主要目的是：為了在沒有多執行緒競爭的情況下儘量減少不必要的輕量級鎖執行路徑。因為輕量級鎖的加鎖解鎖操作是需要依賴多次CAS原子指令的，而偏向鎖只需要在置換ThreadID的時候依賴一次CAS原子指令（由於一旦出現多執行緒競爭的情況就必須撤銷偏向鎖，所以偏向鎖的撤銷操作的效能損耗也必須小於節省下來的CAS原子指令的效能消耗）。
那麼偏向鎖是如何來減少不必要的CAS操作呢？首先我們看下無競爭下鎖存在什麼問題：CAS為什麼會引入本地延遲？這要從SMP（對稱多處理器）架構說起，下圖大概表明了SMP的結構：
SMP（對稱多處理器）架構
而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）架構： 所以，當一個執行緒訪問同步塊並獲取鎖時，會在物件頭和棧幀中的鎖記錄裡儲存鎖偏向的執行緒ID，以後該執行緒進入和退出同步塊時不需要花費CAS操作來爭奪鎖資源，只需要檢查是否為偏向鎖、鎖標識為以及ThreadID即可，處理流程如下：
偏向鎖的釋放採用了一種只有競爭才會釋放鎖的機制，執行緒是不會主動去釋放偏向鎖，需要等待其他執行緒來競爭。偏向鎖的撤銷需要等待全域性安全點（這個時間點是上沒有正在執行的程式碼）。其步驟如下：
偏向鎖的獲取和釋放過程
4.6 輕量級鎖
引入輕量級鎖的主要目的是在沒有多執行緒競爭的前提下，減少傳統的重量級鎖使用作業系統互斥量產生的效能消耗。當關閉偏向鎖功能或者多個執行緒競爭偏向鎖導致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖，其步驟如下：
1.線上程進入同步塊時，如果同步物件鎖狀態為無鎖狀態（鎖標誌位為“01”狀態，是否為偏向鎖為“0”），虛擬機器首先將在當前執行緒的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於儲存鎖物件目前的Mark Word的拷貝，官方稱之為 Displaced Mark Word。此時執行緒堆疊與物件頭的狀態如下圖所示：
輕量級鎖CAS操作之前執行緒堆疊與物件的狀態2.拷貝物件頭中的Mark Word複製到鎖記錄（Lock Record）中；
3.拷貝成功後，虛擬機器將使用CAS操作嘗試將物件Mark Word中的Lock Word更新為指向當前執行緒Lock Record的指標，並將Lock record裡的owner指標指向object mark word。如果更新成功，則執行步驟（4），否則執行步驟（5）；
4.如果這個更新動作成功了，那麼當前執行緒就擁有了該物件的鎖，並且物件Mark Word的鎖標誌位設定為“00”，即表示此物件處於輕量級鎖定狀態，此時執行緒堆疊與物件頭的狀態如下圖所示：
輕量級鎖CAS操作之後執行緒堆疊與物件的狀態
5.如果這個更新操作失敗了，虛擬機器首先會檢查物件Mark Word中的Lock Word是否指向當前執行緒的棧幀，如果是，就說明當前執行緒已經擁有了這個物件的鎖，那就可以直接進入同步塊繼續執行。否則說明多個執行緒競爭鎖，進入自旋執行（3），若自旋結束時仍未獲得鎖，輕量級鎖就要膨脹為重量級鎖，鎖標誌的狀態值變為“10”，Mark Word中儲存的就是指向重量級鎖（互斥量）的指標，當前執行緒以及後面等待鎖的執行緒也要進入阻塞狀態。
輕量級鎖的釋放也是通過CAS操作來進行的，主要步驟如下：
對於輕量級鎖，其效能提升的依據是“對於絕大部分的鎖，在整個生命週期內都是不會存在競爭的”，如果打破這個依據則除了互斥的開銷外，還有額外的CAS操作，因此在有多執行緒競爭的情況下，輕量級鎖比重量級鎖更慢。 輕量級鎖的獲取和釋放過程
1.為什麼升級為輕量鎖時要把物件頭裡的Mark Word複製到執行緒棧的鎖記錄中呢？
2.為什麼會嘗試CAS不成功以及什麼情況下會不成功？
4.7 重量級鎖
Synchronized是通過物件內部的一個叫做監視器鎖（Monitor）來實現的。但是監視器鎖本質又是依賴於底層的作業系統的Mutex Lock來實現的。而作業系統實現執行緒之間的切換這就需要從使用者態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間，這就是為什麼Synchronized效率低的原因。因此，這種依賴於作業系統Mutex Lock所實現的鎖我們稱之為“重量級鎖”。
4.8 重量級鎖、輕量級鎖和偏向鎖之間轉換
重量級鎖、輕量級鎖和偏向鎖之間轉換
Synchronized偏向鎖、輕量級鎖及重量級鎖轉換流程
5 鎖的優劣
各種鎖並不是相互代替的，而是在不同場景下的不同選擇，絕對不是說重量級鎖就是不合適的。每種鎖是隻能升級，不能降級，即由偏向鎖->輕量級鎖->重量級鎖，而這個過程就是開銷逐漸加大的過程。
在第3種情況下進入同步程式碼塊就要做偏向鎖建立、偏向鎖撤銷、輕量級鎖建立、升級到重量級鎖，最終還是得靠重量級鎖來解決問題，那這樣的代價就比直接用重量級鎖要大不少了。所以使用哪種技術，一定要看其所處的環境及場景，在絕大多數的情況下，偏向鎖是有效的，這是基於HotSpot作者發現的“大多數鎖只會由同一執行緒併發申請”的經驗規律。
鎖的優劣