深刻分析Synchronized原理(阿里面試題)

時間 2019-11-20

原文原文鏈接

還有一篇講解lock的實現原理，參考：解決多線程安全問題-無非兩個方法synchronized和lock 具體原理以及如何獲取鎖AQS算法 (百度-美團)html

記得開始學習Java的時候，一遇到多線程狀況就使用synchronized，相對於當時的咱們來講synchronized是這麼的神奇而又強大，那個時候咱們賦予它一個名字「同步」，也成爲了咱們解決多線程狀況的百試不爽的良藥。可是，隨着學習的進行咱們知道在JDK1.5以前synchronized是一個重量級鎖，相對於j.u.c.Lock，它會顯得那麼笨重，以致於咱們認爲它不是那麼的高效而慢慢摒棄它。java

不過，隨着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的全部權，過程以下：
1. 若是monitor的進入數爲0，則該線程進入monitor，而後將進入數設置爲1，該線程即爲monitor的全部者；
2. 若是線程已經佔有該monitor，只是從新進入，則進入monitor的進入數加1；
3. 若是其餘線程已經佔用了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對象頭具體結構描述以下：

Java對象頭結構組成

Mark Word用於存儲對象自身的運行時數據，如：哈希碼（HashCode）、GC分代年齡、鎖狀態標誌、線程持有的鎖、偏向線程 ID、偏向時間戳等。好比鎖膨脹就是藉助Mark Word的偏向的線程ID 參考：JAVA鎖的膨脹過程和優化(阿里) 阿里也常常問的問題

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

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>();
    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的結構：

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開始支持），具體參考：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便可，處理流程以下：

檢測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。此時線程堆棧與對象頭的狀態以下圖所示：

輕量級鎖CAS操做以前線程堆棧與對象的狀態
拷貝對象頭中的Mark Word複製到鎖記錄（Lock Record）中；
拷貝成功後，虛擬機將使用CAS操做嘗試將對象Mark Word中的Lock Word更新爲指向當前線程Lock Record的指針，並將Lock record裏的owner指針指向object mark word。若是更新成功，則執行步驟（4），不然執行步驟（5）；
若是這個更新動做成功了，那麼當前線程就擁有了該對象的鎖，而且對象Mark Word的鎖標誌位設置爲「00」，即表示此對象處於輕量級鎖定狀態，此時線程堆棧與對象頭的狀態以下圖所示：

輕量級鎖CAS操做以後線程堆棧與對象的狀態
若是這個更新操做失敗了，虛擬機首先會檢查對象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 重量級鎖、輕量級鎖和偏向鎖之間轉換

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

Synchronized偏向鎖、輕量級鎖及重量級鎖轉換流程

5 鎖的優劣

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

若是是單線程使用，那偏向鎖毫無疑問代價最小，而且它就能解決問題，連CAS都不用作，僅僅在內存中比較下對象頭就能夠了；

若是出現了其餘線程競爭，則偏向鎖就會升級爲輕量級鎖；

若是其餘線程經過必定次數的CAS嘗試沒有成功，則進入重量級鎖；

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