【死磕Java並發】-----深入分析synchronized的實作原理

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

誠然，隨著Javs SE 1.6對synchronized進行的各種優化後，synchronized並不會顯得那麼重了。下面跟著LZ一起來探索synchronized的實作機制、Java是如何對它進行了優化、鎖定優化機制、鎖定的儲存結構和升級過程；

實作原理

##synchronized可以保證方法或程式碼區塊在運行時，同一時刻只有一個方法可以進入到臨界區，同時它還可以保證共享變數的記憶體可見性

Java中每一個物件都可以作為鎖，這是synchronized實現同步的基礎：

1. 普通同步方法，鎖是當前實例物件
2. 靜態同步方法，鎖定是當前類別的class物件
3. 同步方法區塊，鎖定是括號裡面的物件

當一個執行緒存取同步程式碼區塊時，它首先是需要被鎖才能執行同步程式碼，當退出或拋出例外時必須要釋放鎖，那麼它是如何來實作這個機制的呢？我們先看一段簡單的程式碼：

public class SynchronizedTest {
    public synchronized void test1(){

    }    public void test2(){        synchronized (this){

        }
    }
}

利用javap工具查看產生的class檔案資訊來分析Synchronize的實作

從上面可以看出，同步程式碼區塊是使用monitorenter和monitorexit指令實現的，同步方法（在這看不出來需要看JVM底層實作）依賴的是方法修飾符上的ACC_SYNCHRONIZED實作。

同步程式碼區塊：monitorenter指令插入到同步程式碼區塊的起始位置，monitorexit指令插入到同步程式碼區塊的結束位置，JVM需要保證每一個monitorenter都有一個monitorexit與之相對應。任何物件都有一個monitor與之相關聯，當且一個monitor被持有之後，他將處於鎖定狀態。當執行緒執行到monitorenter指令時，將會嘗試取得物件所對應的monitor所有權，即嘗試取得物件的鎖定；
同步方法：synchronized方法則會被翻譯成普通的方法呼叫與傳回指令如:invokevirtual、areturn指令，在VM字節碼層面並沒有任何特別的指令來實現被synchronized修飾的方法，而是在Class文件的方法表中將該方法的access_flags字段中的synchronized標誌位置1，表示方法是同步方法並使用呼叫該方法的物件或該方法所屬的Class在JVM的內部物件表示Klass做為鎖定物件。 (摘自：http://www.php.cn/)

下面我們來繼續分析，但在深入之前我們需要了解兩個重要的概念：Java物件頭，Monitor。

Java物件頭、monitor

Java物件頭和monitor是實作synchronized的基礎！以下就這兩個概念來做詳細介紹。

Java物件頭

synchronized用的鎖是存在Java物件頭裡的，那麼什麼是Java物件頭呢？ Hotspot虛擬機器的物件頭主要包括兩部分資料：Mark Word（標記欄位）、Klass Pointer（類型指標）。其中Klass Point是是物件指向它的類別元資料的指針，虛擬機器透過這個指針來確定這個物件是哪個類別的實例，Mark Word用於儲存物件自身的執行時間數據，它是實現輕量級鎖定和偏向鎖的關鍵，所以以下將重點闡述

#

Mark Word。
Mark Word用於儲存物件本身的執行時間數據，如雜湊碼（HashCode）、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向線程 ID、偏向時間戳記等等。 Java物件頭一般佔有兩個機器碼（在32位元虛擬機器中，1個機器碼等於4字節，也就是32bit），但是如果物件是陣列類型，則需要三個機器碼，因為JVM虛擬機器可以透過Java物件的元資料資訊來決定Java物件的大小，但無法從陣列的元資料來確認陣列的大小，所以用一塊來記錄陣列長度。下圖是Java物件頭的儲存結構（32位元虛擬機器）：

物件頭資訊是與物件本身定義的資料無關的額外儲存成本，但考慮到虛擬機器的空間效率， Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體中儲存盡量多的數據，它會根據物件的狀態復用自己的儲存空間，也就是說，Mark Word會隨著程式的運作發生變化，變化狀態如下（32位元虛擬機器）：

簡單介紹了Java物件頭，我們下面再看Monitor。

Monitor

什麼是Monitor？我們可以把它理解為一個同步工具，也可以描述為一種同步機制，它通常被描述為一個物件。
與一切皆物件一樣，所有的Java物件是天生的Monitor，每個Java物件都有成為Monitor的潛質，因為在Java的設計中，每個Java物件自打娘胎裡出來就帶了一把看不見的鎖，它叫做內部鎖或Monitor鎖。
Monitor 是執行緒私有的資料結構，每一個執行緒都有一個可用monitor record列表，同時還有一個全域的可用列表。每一個被鎖住的物件都會和一個monitor關聯（物件頭的MarkWord中的LockWord指向monitor的起始位址），同時monitor中有一個Owner欄位存放擁有該鎖的線程的唯一標識，表示該鎖被這個線程佔用。其架構如下：

Owner：初始時為NULL表示目前沒有任何執行緒擁有該monitor record，當執行緒成功擁有該鎖定後保存執行緒唯一標識，當鎖定被釋放時又設定為NULL;
EntryQ:關聯一個系統互斥鎖（semaphore），阻塞所有試圖鎖住monitor record失敗的執行緒。
RcThis:表示blocked或waiting在該monitor record上的所有執行緒的個數。
Nest:用來實現重入鎖定的計數。
HashCode:保存從物件頭拷貝過來的HashCode值（可能還包含GC age）。
Candidate:用來避免不必要的阻塞或等待執行緒喚醒，因為每次只有一個執行緒能夠成功擁有鎖，如果每次前一個釋放鎖的執行緒喚醒所有正在阻塞或等待的線程，會引起不必要的上下文切換（從阻塞到就緒然後因為競爭鎖失敗又被阻塞）從而導致效能嚴重下降。 Candidate只有兩種可能的值0表示沒有需要喚醒的執行緒1表示要喚醒一個繼任執行緒來競爭鎖定。
摘自：Java中synchronized的實作原理與應用）
我們知道synchronized是重量級鎖，效率不怎麼滴，同時這個觀念也一直存在我們腦海裡，不過在jdk 1.6中對synchronize的實現進行了各種優化，使得它顯得不是那麼重了，那麼JVM採用了那些優化手段呢？

鎖定優化

jdk1.6對鎖的實現引入了大量的最佳化，如自旋鎖、適應性自旋鎖、鎖定消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖定操作的開銷。
鎖主要存在四中狀態，依序為：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨著競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是為了提高獲得鎖和釋放鎖的效率。

自旋锁

线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。同时我们发现在许多应用上面，对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。
何谓自旋锁？
所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。怎么等待呢？执行一段无意义的循环即可（自旋）。
自旋等待不能替代阻塞，先不说对处理器数量的要求（多核，貌似现在没有单核的处理器了），虽然它可以避免线程切换带来的开销，但是它占用了处理器的时间。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。所以说，自旋等待的时间（自旋的次数）必须要有一个限度，如果自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。
自旋锁在JDK 1.4.2中引入，默认关闭，但是可以使用-XX:+UseSpinning开开启，在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内部的加锁操作消除。

锁粗化

我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小—仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。
在大多数的情况下，上述观点是正确的，LZ也一直坚持着这个观点。但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗话的概念。
锁粗话概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环之外。

輕量級鎖定

引入輕量級鎖定的主要目的是在多沒有多執行緒競爭的前提下，減少傳統的重量級鎖定使用作業系統互斥所產生的效能消耗。當關閉偏向鎖定功能或多個執行緒競爭偏向鎖定導致偏向鎖定升級為輕量級鎖定，則會嘗試取得輕量級鎖定，其步驟如下：
取得鎖定
1 . 判斷目前物件是否處於無鎖狀態（hashcode、0、01），若是，則JVM首先將在目前執行緒的堆疊幀中建立一個名為鎖定記錄（Lock Record）的空間，用於儲存鎖定物件目前的Mark Word的拷貝（官方把這份拷貝加了一個Displaced前綴，即Displaced Mark Word）；否則執行步驟（3）；
2. JVM利用CAS操作嘗試將物件的Mark  Word更新為指向Lock Record的指正，如果成功表示競爭到鎖，則將鎖定標誌位元變成00（表示此物件處於輕量級鎖定狀態），執行同步操作；如果失敗則執行步驟（3）;
3. 判斷目前對象的Mark Word是否指向當前線程的棧幀，如果是則表示當前線程已經持有當前對象的鎖，則直接執行同步代碼塊；否則只能說明該鎖對像已經被其他線程搶佔了，這時輕量級級鎖需要膨脹為重量級鎖，鎖標誌位元變成10，後面等待的執行緒將會進入阻塞狀態；

釋放鎖
輕量級鎖的釋放也是透過CAS操作來進行的，主要步驟如下：
1. 取出在獲取輕量級鎖保存在Displaced Mark Word中的資料；
2. 用CAS操作將取出的資料替換當前物件的Mark Word中，如果成功，則表示釋放鎖定成功，否則執行（3）；
3. 如果CAS操作替換失敗，表示有其他執行緒嘗試取得該鎖定，則需要在釋放鎖定的同時需要喚醒被掛起的線程。

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

---

下圖是輕量級鎖的獲取和釋放過程

偏向鎖定

引入偏向鎖定主要目的是：為了在無多執行緒競爭的情況下盡量減少不必要的輕量級鎖定執行路徑。上面提到了輕量級鎖的加鎖解鎖操作是需要依賴多次的CAS原子指令。那麼偏向鎖是如何來減少不必要的CAS操作呢？我們可以查看Mark work的結構就明白了。只需要檢查是否為偏向鎖、鎖標識為以及ThreadID即可，處理流程如下：
取得鎖定
1. 偵測Mark Word是否為可偏向狀態，即是否為偏向鎖1，鎖定標識位元為01;
1. 若為可偏向狀態，則測試執行緒ID是否為目前執行緒ID，如果是，則執行步驟（5），否則執行步驟（3）；
1 . 如果線程ID不為當前線程ID，則透過CAS操作競爭鎖，競爭成功，則將Mark Word的線程ID替換為當前線程ID，否則執行線程（4）；
4. 透過CAS競爭鎖失敗，證明目前存在多執行緒競爭情況，當到達全域安全點，獲得偏向鎖的執行緒被掛起，偏向鎖升級為輕量級鎖，然後被阻塞在安全點的執行緒繼續往下執行同步程式碼區塊；
5. 執行同步程式碼區塊

釋放鎖定
偏向鎖定的釋放採用了一種只有競爭才會釋放鎖定的機制，執行緒是不會主動去釋放偏向鎖，需要等待其他執行緒來競爭。偏向鎖的撤銷需要等待全域安全點（這個時間點是上沒有正在執行的程式碼）。其步驟如下：
1. 暫停擁有偏向鎖的線程，判斷鎖對像石是否還處於被鎖定狀態；
2. 撤銷偏向蘇，恢復到無鎖狀態（01）或者輕量級鎖的狀態；

---

下圖是偏向鎖定的獲取和釋放流程

#重量級鎖定

重量級鎖定透過物件內部的監視器（monitor）實現，其中monitor的本質是依賴於底層作業系統的Mutex Lock實現，作業系統實現執行緒之間的切換需要從用戶態到核心態的切換，切換成本非常高。

 以上就是【死磕Java並發】-----深入分析synchronized的實作原理的內容，更多相關內容請關注PHP中文網（www.php.cn）！

#