死磕Synchronized實現原理

時間  2019-11-15
標籤 synchronized 實現 原理 欄目 Java 简体版
原文   原文鏈接

上篇文章咱們已經講了Java Lock類，有興趣的能夠看看：深刻Java Lock鎖，今天咱們來學一下Synchronized，主要有如下知識點：java

  • 基本使用
  • 同步原理
  • Java對象頭
  • Monitor監視器
  • 鎖分類
  • 鎖優化

前言

咱們知道在JDK1.5以前synchronized是一個重量級鎖，相對於j.u.c.Lock，它會顯得那麼笨重，以致於咱們認爲它不是那麼的高效而慢慢摒棄它。segmentfault

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

基本使用

Synchronized的做用主要有兩個:安全

  • 原子性：確保線程互斥的訪問同步代碼；
  • 可見性：保證共享變量的修改可以及時可見，實際上是經過Java內存模型中的 「對一個變量unlock 操做以前，必需要同步到主內存中；若是對一個變量進行lock操做，則將會清空工做內存 中此變量的值，在執行引擎使用此變量前，須要從新從主內存中load操做或assign操做 初始化變量值」 來保證的；

注意，synchronized 內置鎖 是一種 對象鎖（鎖的是對象而非引用變量），做用粒度是對象 ，能夠用來實現對 臨界資源的同步互斥訪問 ，是可重入的。其可重入最大的做用是避免死鎖。數據結構

從語法上講，Synchronized能夠把任何一個非null對象做爲"鎖"，在HotSpot JVM實現中，鎖有個專門的名字：對象監視器（Object Monitor）。多線程

同步原理

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

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

查看反編譯結果app

image

  1. monitorenter：每一個對象都是一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，線程執行monitorenter指令時嘗試獲取monitor的全部權，過程以下：異步

    1. 若是monitor的進入數爲0，則該線程進入monitor，而後將進入數設置爲1，該線程即爲monitor的全部者；
    2. 若是線程已經佔有該monitor，只是從新進入，則進入monitor的進入數加1；
    3. 若是其餘線程已經佔用了monitor，則該線程進入阻塞狀態，直到monitor的進入數爲0，再從新嘗試獲取monitor的全部權；

  2. monitorexit：執行monitorexit的線程必須是objecter所對應的monitor的全部者。指令執行時，monitor的進入數減1，若是減1後進入數爲0，那線程退出monitor，再也不是這個monitor的全部者。其餘被這個monitor阻塞的線程能夠嘗試去獲取這個 monitor 的全部權。佈局

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

經過上面兩段描述，咱們應該能很清楚的看出Synchronized的實現原理，Synchronized的語義底層是經過一個monitor的對象來完成，其實wait/notify等方法也依賴於monitor對象，這就是爲何只有在同步的塊或者方法中才能調用wait/notify等方法，不然會拋出java.lang.IllegalMonitorStateException的異常的緣由。

再來看看同步方法

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

查看反編譯結果

image

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

當方法調用時， 調用指令將會檢查方法的 ACC_SYNCHRONIZED 訪問標誌是否被設置，若是設置了， 執行線程將先獲取monitor，獲取成功以後才能執行方法體， 方法執行完後再釋放monitor。在方法執行期間，其餘任何線程都沒法再得到同一個monitor對象。

兩種同步方式本質上沒有區別，只是方法的同步是一種隱式的方式來實現，無需經過字節碼來完成。兩個指令的執行是JVM經過調用操做系統的互斥原語mutex來實現，被阻塞的線程會被掛起、等待從新調度，會致使「用戶態和內核態」兩個態之間來回切換，對性能有較大影響。

實現機制

Java對象頭

在JVM中，對象在內存中的佈局分爲三塊區域：對象頭、實例數據和對齊填充。以下圖所示：

image

  • 實例數據：存放類的屬性數據信息，包括父類的屬性信息；
  • 對齊填充：因爲虛擬機要求 對象起始地址必須是8字節的整數倍。填充數據不是必須存在的，僅僅是爲了字節對齊；
  • 對象頭：Java對象頭通常佔有2個機器碼（在32位虛擬機中，1個機器碼等於4字節，也就是32bit，在64位虛擬機中，1個機器碼是8個字節，也就是64bit），可是 若是對象是數組類型，則須要3個機器碼，由於JVM虛擬機能夠經過Java對象的元數據信息肯定Java對象的大小，可是沒法從數組的元數據來確認數組的大小，因此用一塊來記錄數組長度。

Synchronized用的鎖就是存在Java對象頭裏的，那麼什麼是Java對象頭呢？Hotspot虛擬機的對象頭主要包括兩部分數據：Mark Word（標記字段）、Class Pointer（類型指針）

  • Class Point是對象指向它的類元數據的指針，虛擬機經過這個指針來肯定這個對象是哪一個類的實例;
  • Mark Word用於存儲對象自身的運行時數據，如哈希碼（HashCode）、GC分代年齡、鎖狀態標誌、線程持有的鎖、偏向線程 ID、偏向時間戳等等,它是實現輕量級鎖和偏向鎖的關鍵.

image

監視器

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

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

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(鎖)；

鎖的優化

從JDK6開始，就對synchronized的實現機制進行了較大調整，包括使用JDK5引進的CAS自旋以外，還增長了自適應的CAS自旋、鎖消除、鎖粗化、偏向鎖、輕量級鎖這些優化策略。因爲此關鍵字的優化使得性能極大提升，同時語義清晰、操做簡單、無需手動關閉，因此推薦在容許的狀況下儘可能使用此關鍵字，同時在性能上此關鍵字還有優化的空間。

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

自旋鎖

線程的阻塞和喚醒須要CPU從用戶態轉爲核心態，頻繁的阻塞和喚醒對CPU來講是一件負擔很重的工做，勢必會給系統的併發性能帶來很大的壓力。同時咱們發如今許多應用上面，對象鎖的鎖狀態只會持續很短一段時間，爲了這一段很短的時間頻繁地阻塞和喚醒線程是很是不值得的。

因此引入自旋鎖，何謂自旋鎖？

所謂自旋鎖，就是指當一個線程嘗試獲取某個鎖時， 若是該鎖已被其餘線程佔用，就一直循環檢測鎖是否被釋放，而不是進入線程掛起或睡眠狀態。

自旋鎖適用於鎖保護的臨界區很小的狀況，臨界區很小的話，鎖佔用的時間就很短。自旋等待不能替代阻塞，雖然它能夠避免線程切換帶來的開銷，可是它佔用了CPU處理器的時間。若是持有鎖的線程很快就釋放了鎖，那麼自旋的效率就很是好，反之，自旋的線程就會白白消耗掉處理的資源，它不會作任何有意義的工做，典型的佔着茅坑不拉屎，這樣反而會帶來性能上的浪費。因此說，自旋等待的時間（自旋的次數）必需要有一個限度，若是自旋超過了定義的時間仍然沒有獲取到鎖，則應該被掛起。

自旋鎖在JDK1.6中默認開啓。同時自旋的默認次數爲10次，能夠經過參數-XX:PreBlockSpin來調整。

若是經過參數-XX:PreBlockSpin來調整自旋鎖的自旋次數，會帶來諸多不便。假如將參數調整爲10，可是系統不少線程都是等你剛剛退出的時候就釋放了鎖（假如多自旋一兩次就能夠獲取鎖），是否是很尷尬。因而JDK1.6引入自適應的自旋鎖，讓虛擬機會變得愈來愈聰明。

適應性自旋鎖

JDK 1.6引入了更加聰明的自旋鎖，即自適應自旋鎖。所謂自適應就意味着自旋的次數再也不是固定的，它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。那它如何進行適應性自旋呢？

線程若是自旋成功了，那麼下次自旋的次數會更加多，由於虛擬機認爲既然上次成功了，那麼這次自旋也頗有可能會再次成功，那麼它就會容許自旋等待持續的次數更多。反之， 若是對於某個鎖，不多有自旋可以成功，那麼在之後要或者這個鎖的時候自旋的次數會減小甚至省略掉自旋過程，以避免浪費處理器資源。

鎖消除

在有些狀況下，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內部的加鎖操做消除。

鎖粗化

在使用同步鎖的時候，須要讓同步塊的做用範圍儘量小一點，僅在共享數據的實際做用域中才進行同步，這樣作的目的是 爲了使須要同步的操做數量儘量縮小，若是存在鎖競爭，那麼等待鎖的線程也能儘快拿到鎖。

在大多數的狀況下，上述觀點是正確的。可是若是一系列的連續加鎖解鎖操做，可能會致使沒必要要的性能損耗，因此引入鎖粗化的概念。

鎖粗話概念比較好理解，就是將多個連續的加鎖、解鎖操做鏈接在一塊兒，擴展成一個範圍更大的鎖

好比上面那個例子，vector每次add的時候都須要加鎖操做，JVM檢測到對同一個對象（vector）連續加鎖、解鎖操做，會合並一個更大範圍的加鎖、解鎖操做，即加鎖解鎖操做會移到for循環以外。

偏向鎖

偏向鎖是JDK6中的重要引進，由於HotSpot做者通過研究實踐發現，在大多數狀況下，鎖不只不存在多線程競爭，並且老是由同一線程屢次得到，爲了讓線程得到鎖的代價更低，引進了偏向鎖。

偏向鎖是在單線程執行代碼塊時使用的機制，若是在多線程併發的環境下（即線程A還沒有執行完同步代碼塊，線程B發起了申請鎖的申請），則必定會轉化爲輕量級鎖或者重量級鎖。

在JDK5中偏向鎖默認是關閉的，而到了JDK6中偏向鎖已經默認開啓。

引入偏向鎖主要目的是：爲了在沒有多線程競爭的狀況下儘可能減小沒必要要的輕量級鎖執行路徑。由於輕量級鎖的加鎖解鎖操做是須要依賴屢次CAS原子指令的，而偏向鎖只須要在置換ThreadID的時候依賴一次CAS原子指令（因爲一旦出現多線程競爭的狀況就必須撤銷偏向鎖，因此偏向鎖的撤銷操做的性能損耗也必須小於節省下來的CAS原子指令的性能消耗）。

輕量級鎖是爲了在線程交替執行同步塊時提升性能，而偏向鎖則是在只有一個線程執行同步塊時進一步提升性能。

那麼偏向鎖是如何來減小沒必要要的CAS操做呢？

如今幾乎全部的鎖都是可重入的，即已經得到鎖的線程能夠屢次鎖住/解鎖監視對象，按照以前的HotSpot設計，每次加鎖/解鎖都會涉及到一些CAS操做（好比對等待隊列的CAS操做）， CAS操做會延遲本地調用，所以偏向鎖的想法是 一旦線程第一次得到了監視對象，以後讓監視對象「偏向」這個線程，以後的屢次調用則能夠避免CAS操做，說白了就是置個變量，若是發現爲true則無需再走各類加鎖/解鎖流程。

當一個線程訪問同步塊並獲取鎖時，會在對象頭和棧幀中的鎖記錄裏存儲鎖偏向的線程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. 執行同步代碼塊；

偏向鎖的釋放採用了 一種只有競爭纔會釋放鎖的機制，線程是不會主動去釋放偏向鎖，須要等待其餘線程來競爭。

偏向鎖升級

偏向鎖的撤銷須要等待全局安全點（這個時間點是上沒有正在執行的代碼）。其步驟以下：

  1. 暫停擁有偏向鎖的線程；
  2. 判斷鎖對象是否還處於被鎖定狀態，否，則恢復到無鎖狀態，以容許其他線程競爭。是，則掛起持有鎖的當前線程，並將指向當前線程的鎖記錄地址的指針放入對象頭Mark Word，升級爲輕量級鎖狀態（00），而後恢復持有鎖的當前線程，進入輕量級鎖的競爭模式；

注意：此處將 當前線程掛起再恢復的過程當中並無發生鎖的轉移，仍然在當前線程手中，只是穿插了個 「將對象頭中的線程ID變動爲指向鎖記錄地址的指針」 這麼個事。

輕量級鎖

引入輕量級鎖的主要目的是在沒有多線程競爭的前提下，減小傳統的重量級鎖使用操做系統互斥量產生的性能消耗。當關閉偏向鎖功能或者多個線程競爭偏向鎖致使偏向鎖升級爲輕量級鎖，則會嘗試獲取輕量級鎖，其步驟以下：

在代碼進入同步塊的時候，若是此同步對象沒有被鎖定（鎖標誌位爲「01」狀態），虛擬機首先將在當前線程的棧幀中創建一個名爲鎖記錄（Lock Record）的空間，用於存儲鎖對象目前的 Mark Word 的拷貝 （官方把這份拷貝加了一個 Displaced 前轍，即Displaced Mark Word ），這時候線程堆棧與對象頭的狀態如圖所示：

image

而後，虛擬機將使用CAS操做嘗試將對象的 Mark Word 更新爲指向 Lock Record 的指針。若是這個更新動做成功了，那麼這個線程就擁有了該對象的鎖，而且對象 Mark Word 的鎖標誌位（Mark Word 的最後 2bit ）將轉變爲 「00」，即表示此對象處於輕量級鎖定狀態，這時候線程堆棧與對象頭的狀態如圖所示：

image

若是這個更新操做失敗了，虛擬機首先會檢查對象的Mark Word是否指向當前線程的棧幀，若是是說明當前線程已經擁有了這個對象的鎖，那就能夠直接進入同步塊繼續執行，不然說明這個鎖對象已經被其餘線程搶佔了。若是有兩條以上的線程爭用同一個鎖，那輕量級鎖就再也不有效，要膨脹爲重量級鎖，鎖標誌的狀態值變爲「10」，Mark Word 中存儲的就是指向重量級鎖（互斥量）的指針，後而等待鎖的線程也要進入阻塞狀態。

對於輕量級鎖，其性能提高的依據是 「對於絕大部分的鎖，在整個生命週期內都是不會存在競爭的」，若是打破這個依據則除了互斥的開銷外，還有額外的CAS操做，所以在有多線程競爭的狀況下，輕量級鎖比重量級鎖更慢。

輕量級鎖所適應的場景是線程交替執行同步塊的狀況，若是存在同一時間訪問同一鎖的狀況，必然就會致使輕量級鎖膨脹爲重量級鎖。

重量級鎖

Synchronized是經過對象內部的一個叫作 監視器鎖（Monitor）來實現的。可是監視器鎖本質又是依賴於底層的操做系統的Mutex Lock來實現的。而操做系統實現線程之間的切換這就須要從用戶態轉換到核心態，這個成本很是高，狀態之間的轉換須要相對比較長的時間，這就是爲何Synchronized效率低的緣由。所以，這種依賴於操做系統Mutex Lock所實現的鎖咱們稱之爲 「重量級鎖」。

鎖的優劣

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

  • 若是是單線程使用，那偏向鎖毫無疑問代價最小，而且它就能解決問題，連CAS都不用作，僅僅在內存中比較下對象頭就能夠了；
  • 若是出現了其餘線程競爭，則偏向鎖就會升級爲輕量級鎖；
  • 若是其餘線程經過必定次數的CAS嘗試沒有成功，則進入重量級鎖；

image

總結

有關Synchronized的知識點暫時先到這裏，後面咱們會學習其餘關鍵字如volatile等。

參考
啃碎併發(七)：深刻分析Synchronized原理

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程