0 前言
記得開始學習Java的時候，一遇到多線程情況就使用synchronized，相對於當時的我們來說synchronized是這麼的神奇而又強大，那個時候我們賦予它一個名字“同步”，也成為了我們解決多線程情況的百試不爽的良藥。但是，
隨著學習的進行我們知道在JDK1.5之前synchronized是一個重量級鎖，相對於j.u.c.Lock，它會顯得那麼笨重，以至於我們認為它不是那麼的高效而慢慢摒棄它。不過，隨著Javs SE 1.6對synchronized進行的各種優化後，synchronized並不會顯得那麼重了。下面來一起探索synchronized的基本使用、實現機制、Java是如何對它進行了優化、鎖優化機制、鎖的存儲結構等升級過程。
1 基本使用
Synchronized是Java中解決併發問題的一種最常用的方法，也是最簡單的一種方法。Synchronized的作用主要有三個：
- 原子性：確保線程互斥的訪問同步代碼；
- 可見性：保證共享變量的修改能夠及時可見，其實是通過Java內存模型中的 “對一個變量unlock操作之前，必須要同步到主內存中；如果對一個變量進行lock操作，則將會清空工作內存中此變量的值，在執行引擎使用此變量前，需要重新從主內存中load操作或assign操作初始化變量值” 來保證的；
- 有序性：有效解決重排序問題，即 “一個unlock操作先行發生(happen-before)於後面對同一個鎖的lock操作”；
從語法上講，Synchronized可以把任何一個非null對象作為"鎖"，在HotSpot JVM實現中，鎖有個專門的名字：對象監視器（Object Monitor）。
Synchronized總共有三種用法：
- 當synchronized作用在實例方法時，監視器鎖（monitor）便是對象實例（this）；
- 當synchronized作用在靜態方法時，監視器鎖（monitor）便是對象的Class實例，因為Class數據存在於永久代，因此靜態方法鎖相當於該類的一個全局鎖；
- 當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");
}
}
}
查看反編譯後結果：
- monitorenter：每個對象都是一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，線程執行monitorenter指令時嘗試獲取monitor的所有權，過程如下：
- 如果monitor的進入數為0，則該線程進入monitor，然後將進入數設置為1，該線程即為monitor的所有者；
- 如果線程已經佔有該monitor，只是重新進入，則進入monitor的進入數加1；
- 如果其他線程已經佔用了monitor，則該線程進入阻塞狀態，直到monitor的進入數為0，再重新嘗試獲取monitor的所有權；
- 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中，對象在內存中的佈局分為三塊區域：對象頭、實例數據和對齊填充。如下圖所示：
- 實例數據：存放類的屬性數據信息，包括父類的屬性信息；
- 對齊填充：由於虛擬機要求 對象起始地址必須是8字節的整數倍。填充數據不是必須存在的，僅僅是為了字節對齊；
- 對象頭：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指令來實現。
- MonitorEnter指令：插入在同步代碼塊的開始位置，當代碼執行到該指令時，將會嘗試獲取該對象Monitor的所有權，即嘗試獲得該對象的鎖；
- 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對象的線程，當多個線程同時訪問一段同步代碼時：
- 首先會進入 _EntryList 集合， 當線程獲取到對象的monitor後，進入 _Owner區域並把monitor中的owner變量設置為當前線程，同時monitor中的計數器count加1；
- 若線程調用 wait() 方法，將釋放當前持有的monitor，owner變量恢復為null，count自減1，同時該線程進入 WaitSet集合中等待被喚醒；
- 若當前線程執行完畢，也將釋放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>();/<string>/<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開始支持），具體參考：en.wikipedia.org/wiki/MESI_p…。
Cache一致性流量的例外情況：
其實也不是所有的CAS都會導致總線風暴，這跟Cache一致性協議有關，具體參考：blogs.oracle.com/dave/entry/…
NUMA(Non Uniform Memory Access Achitecture）架構：
與SMP對應還有非對稱多處理器架構，現在主要應用在一些高端處理器上，主要特點是沒有總線，沒有公用主存，每個Core有自己的內存，針對這種結構此處不做討論。
所以，當一個線程訪問同步塊並獲取鎖時，會在對象頭和棧幀中的鎖記錄裡存儲鎖偏向的線程ID，以後該線程進入和退出同步塊時不需要花費CAS操作來爭奪鎖資源，
只需要檢查是否為偏向鎖、鎖標識為以及ThreadID即可，處理流程如下：- 檢測Mark Word是否為可偏向狀態，即是否為偏向鎖1，鎖標識位為01；
- 若為可偏向狀態，則測試線程ID是否為當前線程ID，如果是，則執行步驟（5），否則執行步驟（3）；
- 如果測試線程ID不為當前線程ID，則通過CAS操作競爭鎖，競爭成功，則將Mark Word的線程ID替換為當前線程ID，否則執行線程（4）；
- 通過CAS競爭鎖失敗，證明當前存在多線程競爭情況，當到達全局安全點，獲得偏向鎖的線程被掛起，偏向鎖升級為輕量級鎖，然後被阻塞在安全點的線程繼續往下執行同步代碼塊；
- 執行同步代碼塊；
偏向鎖的釋放採用了 一種只有競爭才會釋放鎖的機制，線程是不會主動去釋放偏向鎖，需要等待其他線程來競爭 。偏向鎖的撤銷需要 等待全局安全點（這個時間點是上沒有正在執行的代碼）。其步驟如下：
- 暫停擁有偏向鎖的線程；
- 判斷鎖對象是否還處於被鎖定狀態，否，則恢復到無鎖狀態（01），以允許其餘線程競爭。是，則掛起持有鎖的當前線程，並將指向當前線程的鎖記錄地址的指針放入對象頭Mark Word，升級為輕量級鎖狀態（00），然後恢復持有鎖的當前線程，進入輕量級鎖的競爭模式；
注意：此處將 當前線程掛起再恢復的過程中並沒有發生鎖的轉移，仍然在當前線程手中，只是穿插了個 “將對象頭中的線程ID變更為指向鎖記錄地址的指針” 這麼個事。
4.6 輕量級鎖
引入輕量級鎖的主要目的是 在沒有多線程競爭的前提下，減少傳統的重量級鎖使用操作系統互斥量產生的性能消耗。當關閉偏向鎖功能或者多個線程競爭偏向鎖導致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖，其步驟如下：
- 在線程進入同步塊時，如果同步對象鎖狀態為無鎖狀態（鎖標誌位為“01”狀態，是否為偏向鎖為“0”），虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於存儲鎖對象目前的Mark Word的拷貝，官方稱之為 Displaced Mark Word。此時線程堆棧與對象頭的狀態如下圖所示：
- 拷貝對象頭中的Mark Word複製到鎖記錄（Lock Record）中；
- 拷貝成功後，虛擬機將使用CAS操作嘗試將對象Mark Word中的Lock Word更新為指向當前線程Lock Record的指針，並將Lock record裡的owner指針指向object mark word。如果更新成功，則執行步驟（4），否則執行步驟（5）；
- 如果這個更新動作成功了，那麼當前線程就擁有了該對象的鎖，並且對象Mark Word的鎖標誌位設置為“00”，即表示此對象處於輕量級鎖定狀態，此時線程堆棧與對象頭的狀態如下圖所示：
- 如果這個更新操作失敗了，虛擬機首先會檢查對象Mark Word中的Lock Word是否指向當前線程的棧幀，如果是，就說明當前線程已經擁有了這個對象的鎖，那就可以直接進入同步塊繼續執行。否則說明多個線程競爭鎖，進入自旋執行（3），若自旋結束時仍未獲得鎖，輕量級鎖就要膨脹為重量級鎖，鎖標誌的狀態值變為“10”，Mark Word中存儲的就是指向重量級鎖（互斥量）的指針，當前線程以及後面等待鎖的線程也要進入阻塞狀態。
輕量級鎖的釋放也是通過CAS操作來進行的，主要步驟如下：
- 通過CAS操作嘗試把線程中複製的Displaced Mark Word對象替換當前的Mark Word；
- 如果替換成功，整個同步過程就完成了，恢復到無鎖狀態（01）；
- 如果替換失敗， 說明有其他線程嘗試過獲取該鎖（此時鎖已膨脹），那就要在釋放鎖的同時，喚醒被掛起的線程；
對於輕量級鎖，其性能提升的依據是 “對於絕大部分的鎖，在整個生命週期內都是不會存在競爭的”，如果打破這個依據則除了互斥的開銷外，還有額外的CAS操作，因此在有多線程競爭的情況下，輕量級鎖比重量級鎖更慢。
- 為什麼升級為輕量鎖時要把對象頭裡的Mark Word複製到線程棧的鎖記錄中呢？
因為在申請對象鎖時 需要以該值作為CAS的比較條件，同時在升級到重量級鎖的時候，能通過這個比較判定是否在持有鎖的過程中此鎖被其他線程申請過，如果被其他線程申請了，則在釋放鎖的時候要喚醒被掛起的線程。
- 為什麼會嘗試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 鎖的優劣
各種鎖並不是相互代替的，而是在不同場景下的不同選擇，絕對不是說重量級鎖就是不合適的。每種鎖是隻能升級，不能降級，即由偏向鎖->輕量級鎖->重量級鎖，而這個過程就是開銷逐漸加大的過程。
- 如果是單線程使用，那偏向鎖毫無疑問代價最小，並且它就能解決問題，連CAS都不用做，僅僅在內存中比較下對象頭就可以了；
- 如果出現了其他線程競爭，則偏向鎖就會升級為輕量級鎖；
- 如果其他線程通過一定次數的CAS嘗試沒有成功，則進入重量級鎖；
在第3種情況下進入同步代碼塊就 要做偏向鎖建立、偏向鎖撤銷、輕量級鎖建立、升級到重量級鎖，最終還是得靠重量級鎖來解決問題，那這樣的代價就比直接用重量級鎖要大不少了。所以使用哪種技術，一定要看其所處的環境及場景，在絕大多數的情況下，偏向鎖是有效的，這是基於HotSpot作者發現的“大多數鎖只會由同一線程併發申請”的經驗規律。
如果對java微服務、分佈式、高併發、高可用、大型互聯網架構技術、面試經驗交流。感興趣可以關注我的頭條號，我會在微頭條不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。歡迎分享，歡迎評論，歡迎轉發
閱讀更多 架構師交流圈 的文章
