☆啃碎併發（七）：深入分析Synchronized原理

摘要： 0 前言 記得開始學習Java的時候，一遇到多執行緒情況就使用synchronized，相對於當時的我們來說synchronized是這麼的神奇而又強大，那個時候我們賦予它一個名字“同步”，也成為了我們解決多執行緒情況的百試不爽的良藥。但是， 隨著學習的進行我們知道在JDK1.5之前sy...

0 前言

記得開始學習Java的時候，一遇到多執行緒情況就使用synchronized，相對於當時的我們來說synchronized是這麼的神奇而又強大，那個時候我們賦予它一個名字“同步”，也成為了我們解決多執行緒情況的百試不爽的良藥。但是， 隨著學習的進行我們知道在JDK1.5之前synchronized是一個重量級鎖，相對於j.u.c.Lock，它會顯得那麼笨重，以至於我們認為它不是那麼的高效而慢慢摒棄它 。

不過， 隨著Javs SE 1.6對synchronized進行的各種優化後，synchronized並不會顯得那麼重了 。下面來一起探索synchronized的基本使用、實現機制、Java是如何對它進行了優化、鎖優化機制、鎖的儲存結構等升級過程。

1 基本使用

Synchronized是Java中解決併發問題的一種最常用的方法，也是最簡單的一種方法。 Synchronized的作用主要有三個 ：

1. 原子性 ：確保執行緒互斥的訪問同步程式碼；
2. 可見性 ：保證共享變數的修改能夠及時可見，其實是通過Java記憶體模型中的 “對一個變數unlock操作之前，必須要同步到主記憶體中；如果對一個變數進行lock操作，則將會清空工作記憶體中此變數的值，在執行引擎使用此變數前，需要重新從主記憶體中load操作或assign操作初始化變數值” 來保證的；
3. 有序性 ：有效解決重排序問題，即 “一個unlock操作先行發生(happen-before)於後面對同一個鎖的lock操作” ；

從語法上講， Synchronized可以把任何一個非null物件作為"鎖" ，在HotSpot JVM實現中，鎖有個專門的名字： 物件監視器（Object Monitor） 。

Synchronized總共有三種用法：

1. 當synchronized作用在例項方法時， 監視器鎖（monitor）便是物件例項（this） ；
2. 當synchronized作用在靜態方法時， 監視器鎖（monitor）便是物件的Class例項 ，因為Class資料存在於永久代， 因此靜態方法鎖相當於該類的一個全域性鎖 ；
3. 當synchronized作用在某一個物件例項時， 監視器鎖（monitor）便是括號括起來的物件例項 ；

注意，synchronized 內建鎖 是一種 物件鎖（鎖的是物件而非引用變數） ， 作用粒度是物件 ，可以用來實現對 臨界資源的同步互斥訪問 ，是 可重入 的。 其可重入最大的作用是避免死鎖 ，如：

子類同步方法呼叫了父類同步方法，如沒有可重入的特性，則會發生死鎖；

2 同步原理

資料同步需要依賴鎖，那鎖的同步又依賴誰？ synchronized給出的答案是在軟體層面依賴JVM，而j.u.c.Lock給出的答案是在硬體層面依賴特殊的CPU指令 。

當一個執行緒訪問同步程式碼塊時， 首先是需要得到鎖才能執行同步程式碼，當退出或者丟擲異常時必須要釋放鎖 ，那麼它是如何來實現這個機制的呢？我們先看一段簡單的程式碼：

package com.paddx.test.concurrent;

public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println("Method 1 start");
}
}
}

檢視反編譯後結果：

1. monitorenter：每個物件都是一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，執行緒執行monitorenter指令時嘗試獲取monitor的所有權，過程如下：

   1. 如果monitor的進入數為0 ，則該執行緒進入monitor，然後將進入數設定為1，該執行緒即為monitor的所有者；
   2. 如果執行緒已經佔有該monitor ，只是重新進入，則進入monitor的進入數加1；
   3. 如果其他執行緒已經佔用了monitor ，則該執行緒進入阻塞狀態，直到monitor的進入數為0，再重新嘗試獲取monitor的所有權；

2. monitorexit：執行monitorexit的執行緒必須是objectref所對應的monitor的所有者。 指令執行時，monitor的進入數減1，如果減1後進入數為0，那執行緒退出monitor，不再是這個monitor的所有者 。其他被這個monitor阻塞的執行緒可以嘗試去獲取這個 monitor 的所有權。

   monitorexit指令出現了兩次，第1次為同步正常退出釋放鎖；第2次為發生非同步退出釋放鎖；

通過上面兩段描述，我們應該能很清楚的看出Synchronized的實現原理， Synchronized的語義底層是通過一個monitor的物件來完成，其實wait/notify等方法也依賴於monitor物件 ，這就是為什麼只有在同步的塊或者方法中才能呼叫wait/notify等方法， 否則會丟擲java.lang.IllegalMonitorStateException的異常的原因 。

再來看一下同步方法：

package com.paddx.test.concurrent;

public class SynchronizedMethod {
public synchronized void method() {
System.out.println("Hello World!");
}
}

檢視反編譯後結果：

從編譯的結果來看，方法的同步並沒有通過指令 monitorenter 和 monitorexit 來完成（理論上其實也可以通過這兩條指令來實現），不過相對於普通方法，其常量池中多了 ACC_SYNCHRONIZED 標示符。 JVM就是根據該標示符來實現方法的同步的 ：

當方法呼叫時， 呼叫指令將會檢查方法的 ACC_SYNCHRONIZED 訪問標誌是否被設定 ，如果設定了， 執行執行緒將先獲取monitor ，獲取成功之後才能執行方法體， 方法執行完後再釋放monitor 。在方法執行期間，其他任何執行緒都無法再獲得同一個monitor物件。

兩種同步方式本質上沒有區別，只是方法的同步是一種隱式的方式來實現，無需通過位元組碼來完成。 兩個指令的執行是JVM通過呼叫作業系統的互斥原語mutex來實現，被阻塞的執行緒會被掛起、等待重新排程 ，會導致“使用者態和核心態”兩個態之間來回切換，對效能有較大影響。

3 同步概念

3.1 Java物件頭

在JVM中，物件在記憶體中的佈局分為三塊區域： 物件頭、例項資料和對齊填充 。如下圖所示：

1. 例項資料 ：存放類的屬性資料資訊，包括父類的屬性資訊；
2. 對齊填充 ：由於虛擬機器要求 物件起始地址必須是8位元組的整數倍 。填充資料不是必須存在的，僅僅是為了位元組對齊；
3. 物件頭 ： Java物件頭一般佔有2個機器碼 （在32位虛擬機器中，1個機器碼等於4位元組，也就是32bit，在64位虛擬機器中，1個機器碼是8個位元組，也就是64bit），但是 如果物件是陣列型別，則需要3個機器碼，因為JVM虛擬機器可以通過Java物件的元資料資訊確定Java物件的大小 ，但是無法從陣列的元資料來確認陣列的大小，所以用一塊來記錄陣列長度。

Synchronized用的鎖就是存在Java物件頭裡的，那麼什麼是Java物件頭呢？Hotspot虛擬機器的物件頭主要包括兩部分資料： Mark Word（標記欄位）、Class Pointer（型別指標） 。其中 Class Pointer是物件指向它的類元資料的指標 ，虛擬機器通過這個指標來確定這個物件是哪個類的例項， Mark Word用於儲存物件自身的執行時資料，它是實現輕量級鎖和偏向鎖的關鍵 。 Java物件頭具體結構描述如下：

Mark Word用於儲存物件自身的執行時資料，如：雜湊碼（HashCode）、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒 ID、偏向時間戳等。下圖是Java物件頭 無鎖狀態下Mark Word部分的儲存結構 （32位虛擬機器）：

物件頭資訊是與物件自身定義的資料無關的額外儲存成本，但是考慮到虛擬機器的空間效率， Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲存儘量多的資料，它會根據物件的狀態複用自己的儲存空間 ，也就是說， Mark Word會隨著程式的執行發生變化，可能變化為儲存以下4種資料 ：

在64位虛擬機器下， Mark Word是64bit大小的 ，其儲存結構如下：

物件頭的最後兩位儲存了鎖的標誌位， 01是初始狀態，未加鎖 ，其物件頭裡儲存的是物件本身的雜湊碼，隨著鎖級別的不同，物件頭裡會儲存不同的內容。 偏向鎖儲存的是當前佔用此物件的執行緒ID ； 而輕量級則儲存指向執行緒棧中鎖記錄的指標 。從這裡我們可以看到，“鎖”這個東西， 可能是個鎖記錄+物件頭裡的引用指標 （判斷執行緒是否擁有鎖時將執行緒的鎖記錄地址和物件頭裡的指標地址比較)， 也可能是物件頭裡的執行緒ID （判斷執行緒是否擁有鎖時將執行緒的ID和物件頭裡儲存的執行緒ID比較）。

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的內部結構：

Lock Record	描述
Owner	初始時為NULL表示當前沒有任何執行緒擁有該monitor record， 當執行緒成功擁有該鎖後儲存執行緒唯一標識 ，當鎖被釋放時又設定為NULL；
EntryQ	關聯一個系統互斥鎖（semaphore）， 阻塞所有試圖鎖住monitor record失敗的執行緒 ；
RcThis	表示blocked或waiting在該monitor record上的所有執行緒的個數 ；
Nest	用來實現 重入鎖的計數 ；
HashCode	儲存從物件頭拷貝過來的HashCode值（可能還包含GC age）。
Candidate	用來避免不必要的阻塞或等待執行緒喚醒，因為每一次只有一個執行緒能夠成功擁有鎖，如果每次前一個釋放鎖的執行緒喚醒所有正在阻塞或等待的執行緒，會引起不必要的上下文切換（從阻塞到就緒然後因為競爭鎖失敗又被阻塞）從而導致效能嚴重下降。 Candidate只有兩種可能的值0表示沒有需要喚醒的執行緒1表示要喚醒一個繼任執行緒來競爭鎖 。

3.3 監視器（Monitor）

任何一個物件都有一個Monitor與之關聯，當且一個Monitor被持有後，它將處於鎖定狀態。Synchronized在JVM裡的實現都是 基於進入和退出Monitor物件來實現方法同步和程式碼塊同步 ，雖然具體實現細節不一樣，但是都可以通過成對的MonitorEnter和MonitorExit指令來實現。

1. MonitorEnter指令：插入在同步程式碼塊的開始位置 ，當代碼執行到該指令時，將會嘗試獲取該物件Monitor的所有權，即嘗試獲得該物件的鎖；
2. MonitorExit指令：插入在方法結束處和異常處 ，JVM保證每個MonitorEnter必須有對應的MonitorExit；

那什麼是Monitor？可以把它理解為 一個同步工具 ，也可以描述為 一種同步機制 ，它通常被 描述為一個物件 。

與一切皆物件一樣，所有的Java物件是天生的Monitor，每一個Java物件都有成為Monitor的潛質， 因為在Java的設計中 ，每一個Java物件自打孃胎裡出來就帶了一把看不見的鎖，它叫做內部鎖或者Monitor鎖 。

也就是通常說Synchronized的物件鎖，MarkWord鎖標識位為10，其中指標指向的是Monitor物件的起始地址。在Java虛擬機器（HotSpot）中， Monitor是由ObjectMonitor實現的 ，其主要資料結構如下（位於HotSpot虛擬機器原始碼ObjectMonitor.hpp檔案，C++實現的）：

ObjectMonitor() {
_header= NULL;
_count= 0; // 記錄個數
_waiters= 0,
_recursions= 0;
_object= NULL;
_owner= NULL;
_WaitSet= NULL; // 處於wait狀態的執行緒，會被加入到_WaitSet
_WaitSetLock= 0 ;
_Responsible= NULL ;
_succ= NULL ;
_cxq= NULL ;
FreeNext= NULL ;
_EntryList= NULL ; // 處於等待鎖block狀態的執行緒，會被加入到該列表
_SpinFreq= 0 ;
_SpinClock= 0 ;
OwnerIsThread = 0 ;
}

ObjectMonitor中有兩個佇列， _WaitSet 和 _EntryList ，用來儲存ObjectWaiter物件列表（ 每個等待鎖的執行緒都會被封裝成ObjectWaiter物件 ）， _owner指向持有ObjectMonitor物件的執行緒 ，當多個執行緒同時訪問一段同步程式碼時：

1. 首先會進入 _EntryList 集合， 當執行緒獲取到物件的monitor後，進入 _Owner區域並把monitor中的owner變數設定為當前執行緒，同時monitor中的計數器count加1 ；
2. 若執行緒呼叫 wait() 方法， 將釋放當前持有的monitor，owner變數恢復為null，count自減1，同時該執行緒進入 WaitSet集合中等待被喚醒 ；
3. 若當前執行緒執行完畢， 也將釋放monitor（鎖）並復位count的值，以便其他執行緒進入獲取monitor(鎖) ；

同時， Monitor物件存在於每個Java物件的物件頭Mark Word中（儲存的指標的指向），Synchronized鎖便是通過這種方式獲取鎖的 ，也是為什麼Java中任意物件可以作為鎖的原因， 同時notify/notifyAll/wait等方法會使用到Monitor鎖物件，所以必須在同步程式碼塊中使用 。

監視器Monitor有兩種同步方式： 互斥與協作 。多執行緒環境下執行緒之間如果需要共享資料，需要解決互斥訪問資料的問題， 監視器可以確保監視器上的資料在同一時刻只會有一個執行緒在訪問 。

什麼時候需要協作？ 比如：

一個執行緒向緩衝區寫資料，另一個執行緒從緩衝區讀資料，如果讀執行緒發現緩衝區為空就會等待，當寫執行緒向緩衝區寫入資料，就會喚醒讀執行緒， 這裡讀執行緒和寫執行緒就是一個合作關係 。JVM通過Object類的wait方法來使自己等待，在呼叫wait方法後，該執行緒會釋放它持有的監視器，直到其他執行緒通知它才有執行的機會。一個執行緒呼叫notify方法通知在等待的執行緒，這個等待的執行緒並不會馬上執行，而是要通知執行緒釋放監視器後，它重新獲取監視器才有執行的機會。如果剛好喚醒的這個執行緒需要的監視器被其他執行緒搶佔，那麼這個執行緒會繼續等待。Object類中的notifyAll方法可以解決這個問題，它可以喚醒所有等待的執行緒，總有一個執行緒執行。

如上圖所示，一個執行緒通過1號門進入Entry Set(入口區)，如果在入口區沒有執行緒等待，那麼這個執行緒就會獲取監視器成為監視器的Owner，然後執行監視區域的程式碼。如果在入口區中有其它執行緒在等待，那麼新來的執行緒也會和這些執行緒一起等待。執行緒在持有監視器的過程中，有兩個選擇， 一個是正常執行監視器區域的程式碼 ，釋放監視器，通過5號門退出監視器； 還有可能等待某個條件的出現 ，於是它會通過3號門到Wait Set（等待區）休息，直到相應的條件滿足後再通過4號門進入重新獲取監視器再執行。

注意：

當一個執行緒釋放監視器時， 在入口區和等待區的等待執行緒都會去競爭監視器 ，如果入口區的執行緒贏了，會從2號門進入；如果等待區的執行緒贏了會從4號門進入。 只有通過3號門才能進入等待區，在等待區中的執行緒只有通過4號門才能退出等待區 ，也就是說一個執行緒只有在持有監視器時才能執行wait操作，處於等待的執行緒只有再次獲得監視器才能退出等待狀態。

4 鎖的優化

從JDK5引入了現代作業系統新增加的CAS原子操作（ JDK5中並沒有對synchronized關鍵字做優化，而是體現在J.U.C中，所以在該版本concurrent包有更好的效能 ），從JDK6開始，就對synchronized的實現機制進行了較大調整， 包括使用JDK5引進的CAS自旋之外，還增加了自適應的CAS自旋、鎖消除、鎖粗化、偏向鎖、輕量級鎖這些優化策略 。由於此關鍵字的優化使得效能極大提高，同時語義清晰、操作簡單、無需手動關閉，所以推薦在允許的情況下儘量使用此關鍵字，同時在效能上此關鍵字還有優化的空間。

鎖主要存在四種狀態，依次是： 無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態 ，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖。 但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級 。

在 JDK 1.6 中預設是開啟偏向鎖和輕量級鎖的 ，可以通過-XX:-UseBiasedLocking來禁用偏向鎖。

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()方法：

public void vectorTest(){
Vector<String> vector = new Vector<String>();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}

System.out.println(vector);
}

在執行這段程式碼時， JVM可以明顯檢測到變數vector沒有逃逸出方法vectorTest()之外 ，所以JVM可以大膽地將vector內部的加鎖操作消除。

4.4 鎖粗化

在使用同步鎖的時候，需要讓同步塊的作用範圍儘可能小—僅在共享資料的實際作用域中才進行同步，這樣做的目的是 為了使需要同步的運算元量儘可能縮小，如果存在鎖競爭，那麼等待鎖的執行緒也能儘快拿到鎖 。

在大多數的情況下，上述觀點是正確的。 但是如果一系列的連續加鎖解鎖操作，可能會導致不必要的效能損耗，所以引入鎖粗話的概念 。

鎖粗話概念比較好理解，就是將多個連續的加鎖、解鎖操作連線在一起，擴充套件成一個範圍更大的鎖

如上面例項：

vector每次add的時候都需要加鎖操作，JVM檢測到對同一個物件（vector）連續加鎖、解鎖操作，會合並一個更大範圍的加鎖、解鎖操作，即加鎖解鎖操作會移到for迴圈之外。

4.5 偏向鎖

偏向鎖是JDK6中的重要引進，因為HotSpot作者經過研究實踐發現， 在大多數情況下，鎖不僅不存在多執行緒競爭，而且總是由同一執行緒多次獲得 ，為了讓執行緒獲得鎖的代價更低，引進了偏向鎖。

偏向鎖是在單執行緒執行程式碼塊時使用的機制，如果在多執行緒併發的環境下（即執行緒A尚未執行完同步程式碼塊，執行緒B發起了申請鎖的申請），則一定會轉化為輕量級鎖或者重量級鎖。

在JDK5中偏向鎖預設是關閉的，而到了JDK6中偏向鎖已經預設開啟。如果併發數較大同時同步程式碼塊執行時間較長，則被多個執行緒同時訪問的概率就很大，就可以使用引數-XX:-UseBiasedLocking來禁止偏向鎖(但這是個JVM引數，不能針對某個物件鎖來單獨設定)。

引入偏向鎖主要目的是： 為了在沒有多執行緒競爭的情況下儘量減少不必要的輕量級鎖執行路徑 。因為輕量級鎖的加鎖解鎖操作是需要依賴多次CAS原子指令的， 而偏向鎖只需要在置換ThreadID的時候依賴一次CAS原子指令 （由於一旦出現多執行緒競爭的情況就必須撤銷偏向鎖，所以偏向鎖的撤銷操作的效能損耗也必須小於節省下來的CAS原子指令的效能消耗）。

輕量級鎖是為了線上程交替執行同步塊時提高效能，而偏向鎖則是在只有一個執行緒執行同步塊時進一步提高效能。

那麼偏向鎖是如何來減少不必要的CAS操作呢？首先我們看下無競爭下鎖存在什麼問題：

現在幾乎所有的鎖都是可重入的，即已經獲得鎖的執行緒可以多次鎖住/解鎖監視物件，按照之前的HotSpot設計，每次加鎖/解鎖都會涉及到一些CAS操作（比如對等待佇列的CAS操作）， CAS操作會延遲本地呼叫 ，因此偏向鎖的想法是 一旦執行緒第一次獲得了監視物件，之後讓監視物件“偏向”這個執行緒，之後的多次呼叫則可以避免CAS操作 ，說白了就是置個變數，如果發現為true則無需再走各種加鎖/解鎖流程。

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開始支援），具體參考： ofollow,noindex">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有自己的記憶體，針對這種結構此處不做討論。

所以，當一個執行緒訪問同步塊並獲取鎖時，會在物件頭和棧幀中的鎖記錄裡儲存鎖偏向的執行緒ID，以後該執行緒進入和退出同步塊時不需要花費CAS操作來爭奪鎖資源， 只需要檢查是否為偏向鎖、鎖標識為以及ThreadID即可，處理流程如下：

1. 檢測Mark Word是否為可偏向狀態 ，即是否為偏向鎖1，鎖標識位為01；
2. 若為可偏向狀態，則測試執行緒ID是否為當前執行緒ID ，如果是，則執行步驟（5），否則執行步驟（3）；
3. 如果測試執行緒ID不為當前執行緒ID ，則通過CAS操作競爭鎖，競爭成功，則將Mark Word的執行緒ID替換為當前執行緒ID，否則執行執行緒（4）；
4. 通過CAS競爭鎖失敗，證明當前存在多執行緒競爭情況，當到達全域性安全點，獲得偏向鎖的執行緒被掛起，偏向鎖升級為輕量級鎖 ，然後被阻塞在安全點的執行緒繼續往下執行同步程式碼塊；
5. 執行同步程式碼塊；

偏向鎖的釋放採用了 一種只有競爭才會釋放鎖的機制，執行緒是不會主動去釋放偏向鎖，需要等待其他執行緒來競爭 。偏向鎖的撤銷需要 等待全域性安全點 （這個時間點是上沒有正在執行的程式碼）。其步驟如下：

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操作來進行的，主要步驟如下：

1. 通過CAS操作嘗試把執行緒中複製的Displaced Mark Word物件替換當前的Mark Word ；
2. 如果替換成功， 整個同步過程就完成了，恢復到無鎖狀態（01） ；
3. 如果替換失敗， 說明有其他執行緒嘗試過獲取該鎖（此時鎖已膨脹），那就要在釋放鎖的同時，喚醒被掛起的執行緒 ；

對於輕量級鎖，其效能提升的依據是 “對於絕大部分的鎖，在整個生命週期內都是不會存在競爭的” ，如果打破這個依據則除了互斥的開銷外，還有額外的CAS操作， 因此在有多執行緒競爭的情況下，輕量級鎖比重量級鎖更慢 。

1. 為什麼升級為輕量鎖時要把物件頭裡的Mark Word複製到執行緒棧的鎖記錄中呢？

   因為在申請物件鎖時 需要以該值作為CAS的比較條件 ，同時在升級到重量級鎖的時候， 能通過這個比較判定是否在持有鎖的過程中此鎖被其他執行緒申請過 ，如果被其他執行緒申請了，則在釋放鎖的時候要喚醒被掛起的執行緒。

2. 為什麼會嘗試CAS不成功以及什麼情況下會不成功？

   CAS本身是不帶鎖機制的，其是通過比較而來。假設如下場景：執行緒A和執行緒B都在物件頭裡的鎖標識為無鎖狀態進入，那麼如執行緒A先更新物件頭為其鎖記錄指標成功之後，執行緒B再用CAS去更新，就會發現此時的物件頭已經不是其操作前的物件HashCode了，所以CAS會失敗。也就是說，只有兩個執行緒併發申請鎖的時候會發生CAS失敗。

   然後執行緒B進行CAS自旋，等待物件頭的鎖標識重新變回無鎖狀態或物件頭內容等於物件HashCode（因為這是執行緒B做CAS操作前的值），這也就意味著執行緒A執行結束（參見後面輕量級鎖的撤銷，只有執行緒A執行完畢撤銷鎖了才會重置物件頭），此時執行緒B的CAS操作終於成功了，於是執行緒B獲得了鎖以及執行同步程式碼的許可權。如果執行緒A的執行時間較長，執行緒B經過若干次CAS時鐘沒有成功，則鎖膨脹為重量級鎖，即執行緒B被掛起阻塞、等待重新排程。

此處，如何理解“輕量級”？ “輕量級”是相對於使用作業系統互斥量來實現的傳統鎖而言的 。但是，首先需要強調一點的是， 輕量級鎖並不是用來代替重量級鎖的，它的本意是在沒有多執行緒競爭的前提下，減少傳統的重量級鎖使用產生的效能消耗 。

輕量級鎖所適應的場景是執行緒交替執行同步塊的情況，如果存在同一時間訪問同一鎖的情況，必然就會導致輕量級鎖膨脹為重量級鎖。

4.7 重量級鎖

Synchronized是通過物件內部的一個叫做 監視器鎖（Monitor）來實現的 。 但是監視器鎖本質又是依賴於底層的作業系統的Mutex Lock來實現的。而作業系統實現執行緒之間的切換這就需要從使用者態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間 ，這就是為什麼Synchronized效率低的原因。因此，這種依賴於作業系統Mutex Lock所實現的鎖我們稱之為 “重量級鎖” 。

4.8 重量級鎖、輕量級鎖和偏向鎖之間轉換

5 鎖的優劣

各種鎖並不是相互代替的， 而是在不同場景下的不同選擇 ，絕對不是說重量級鎖就是不合適的。 每種鎖是隻能升級，不能降級，即由偏向鎖->輕量級鎖->重量級鎖 ，而這個過程就是開銷逐漸加大的過程。

1. 如果是單執行緒使用，那偏向鎖毫無疑問代價最小 ，並且它就能解決問題，連CAS都不用做，僅僅在記憶體中比較下物件頭就可以了；
2. 如果出現了其他執行緒競爭 ，則偏向鎖就會升級為輕量級鎖；
3. 如果其他執行緒通過一定次數的CAS嘗試沒有成功 ，則進入重量級鎖；

在第3種情況下進入同步程式碼塊就 要做偏向鎖建立、偏向鎖撤銷、輕量級鎖建立、升級到重量級鎖，最終還是得靠重量級鎖來解決問題，那這樣的代價就比直接用重量級鎖要大不少了 。所以使用哪種技術，一定要看其所處的環境及場景， 在絕大多數的情況下，偏向鎖是有效的，這是基於HotSpot作者發現的“大多數鎖只會由同一執行緒併發申請”的經驗規律 。

6 擴充套件資料

1. JVM原始碼分析之synchronized實現
2. 自旋鎖、排隊自旋鎖、MCS鎖、CLH鎖
3. 深入理解Java併發之synchronized實現原理