來源：juejin.cn/post/6844903726545633287
關于synchronized的底層實作，網上有很多文章了，但是很多文章要么作者根本沒看代碼，僅僅是根據網上其他文章總結、照搬而成，難免有些錯誤；要么很多點都是一筆帶過，對于為什么這樣實作沒有一個說法，讓像我這樣的讀者意猶未盡，
本系列文章將對HotSpot的synchronized鎖實作進行全面分析，內容包括偏向鎖、輕量級鎖、重量級鎖的加鎖、解鎖、鎖升級流程的原理及原始碼分析，希望給在研究synchronized路上的同學一些幫助，
大概花費了兩周的實作看代碼（花費了這么久時間有些懺愧，主要是對C++、JVM底層機制、JVM除錯以及匯編代碼不太熟），將synchronized涉及到的代碼基本都看了一遍，其中還包括在JVM中添加日志驗證自己的猜想，總的來說目前對synchronized這塊有了一個比較全面清晰的認識，但水平有限，有些細節難免有些疏漏，還望請大家指正，
本篇文章將對synchronized機制做個大致的介紹，包括用以承載鎖狀態的物件頭、鎖的幾種形式、各種形式鎖的加鎖和解鎖流程、什么時候會發生鎖升級，需要注意的是本文旨在介紹背景和概念，在講述一些流程的時候，只提到了主要case，對于實作細節、運行時的不同分支都在后面的文章中詳細分析，
本人看的JVM版本是jdk8u，具體版本號以及代碼可以在這里看到，
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/9ce27f0a4683
一、synchronized簡介
Java中提供了兩種實作同步的基礎語意：synchronized方法和synchronized塊， 我們來看個demo：
public class SyncTest {
public void syncBlock(){
synchronized (this){
System.out.println("hello block");
}
}
public synchronized void syncMethod(){
System.out.println("hello method");
}
}
當SyncTest.java被編譯成class檔案的時候，synchronized關鍵字和synchronized方法的位元組碼略有不同，我們可以用javap -v 命令查看class檔案對應的JVM位元組碼資訊，部分資訊如下：
{
public void syncBlock();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=3, args_size=1
0: aload_0
1: dup
2: astore_1
3: monitorenter // monitorenter指令進入同步塊
4: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
7: ldc #3 // String hello block
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
12: aload_1
13: monitorexit // monitorexit指令退出同步塊
14: goto 22
17: astore_2
18: aload_1
19: monitorexit // monitorexit指令退出同步塊
20: aload_2
21: athrow
22: return
Exception table:
from to target type
4 14 17 any
17 20 17 any
public synchronized void syncMethod();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED //添加了ACC_SYNCHRONIZED標記
Code:
stack=2, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #5 // String hello method
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
}
從上面的中文注釋處可以看到，對于synchronized關鍵字而言，javac在編譯時，會生成對應的monitorenter和monitorexit指令分別對應synchronized同步塊的進入和退出，有兩個monitorexit指令的原因是：為了保證拋例外的情況下也能釋放鎖，所以javac為同步代碼塊添加了一個隱式的try-finally，在finally中會呼叫monitorexit命令釋放鎖，
而對于synchronized方法而言，javac為其生成了一個ACCSYNCHRONIZED關鍵字，在JVM進行方法呼叫時，發現呼叫的方法被ACCSYNCHRONIZED修飾，則會先嘗試獲得鎖，
在JVM底層，對于這兩種synchronized語意的實作大致相同，在后文中會選擇一種進行詳細分析，
因為本文旨在分析synchronized的實作原理，因此對于其使用的一些問題就不贅述了，不了解的朋友可以看看這篇文章，
https://blog.csdn.net/luoweifu/article/details/46613015
二、鎖的幾種形式
傳統的鎖（也就是下文要說的重量級鎖）依賴于系統的同步函式，在linux上使用mutex互斥鎖，最底層實作依賴于futex，關于futex可以看這些文章，這些同步函式都涉及到用戶態和內核態的切換、行程的背景關系切換，成本較高，對于加了synchronized關鍵字但運行時并沒有多執行緒競爭，或兩個執行緒接近于交替執行的情況，使用傳統鎖機制無疑效率是會比較低的，
https://github.com/farmerjohngit/myblog/issues/8
在JDK 1.6之前,synchronized只有傳統的鎖機制，因此給開發者留下了synchronized關鍵字相比于其他同步機制性能不好的印象，
在JDK 1.6引入了兩種新型鎖機制：偏向鎖和輕量級鎖，它們的引入是為了解決在沒有多執行緒競爭或基本沒有競爭的場景下因使用傳統鎖機制帶來的性能開銷問題，
在看這幾種鎖機制的實作前，我們先來了解下物件頭，它是實作多種鎖機制的基礎，
1.物件頭
因為在Java中任意物件都可以用作鎖，因此必定要有一個映射關系，存盤該物件以及其對應的鎖資訊（比如當前哪個執行緒持有鎖，哪些執行緒在等待），一種很直觀的方法是，用一個全域map，來存盤這個映射關系，但這樣會有一些問題：需要對map做執行緒安全保障，不同的synchronized之間會相互影響，性能差；另外當同步物件較多時，該map可能會占用比較多的記憶體，
所以最好的辦法是將這個映射關系存盤在物件頭中，因為物件頭本身也有一些hashcode、GC相關的資料，所以如果能將鎖資訊與這些資訊共存在物件頭中就好了，
在JVM中，物件在記憶體中除了本身的資料外還會有個物件頭，對于普通物件而言，其物件頭中有兩類資訊：mark word和型別指標，另外對于陣列而言還會有一份記錄陣列長度的資料，
型別指標是指向該物件所屬類物件的指標，mark word用于存盤物件的HashCode、GC分代年齡、鎖狀態等資訊，在32位系統上mark word長度為32位元組，64位系統上長度為64位元組，為了能在有限的空間里存盤下更多的資料，其存盤格式是不固定的，在32位系統上各狀態的格式如下：
可以看到鎖資訊也是存在于物件的mark word中的，當物件狀態為偏向鎖（biasable）時，mark word存盤的是偏向的執行緒ID；當狀態為輕量級鎖（lightweight locked）時，mark word存盤的是指向執行緒堆疊中Lock Record的指標；當狀態為重量級鎖（inflated）時，為指向堆中的monitor物件的指標，
2.重量級鎖
重量級鎖是我們常說的傳統意義上的鎖，其利用作業系統底層的同步機制去實作Java中的執行緒同步，
重量級鎖的狀態下，物件的mark word為指向一個堆中monitor物件的指標，
一個monitor物件包括這么幾個關鍵欄位：cxq（下圖中的ContentionList），EntryList ，WaitSet，owner，
其中cxq ，EntryList ，WaitSet都是由ObjectWaiter的鏈表結構，owner指向持有鎖的執行緒，
當一個執行緒嘗試獲得鎖時，如果該鎖已經被占用，則會將該執行緒封裝成一個ObjectWaiter物件插入到cxq的佇列尾部，然后暫停當前執行緒，當持有鎖的執行緒釋放鎖前，會將cxq中的所有元素移動到EntryList中去，并喚醒EntryList的隊首執行緒，
如果一個執行緒在同步塊中呼叫了Object#wait方法，會將該執行緒對應的ObjectWaiter從EntryList移除并加入到WaitSet中，然后釋放鎖，當wait的執行緒被notify之后，會將對應的ObjectWaiter從WaitSet移動到EntryList中，
以上只是對重量級鎖流程的一個簡述，其中涉及到的很多細節，比如ObjectMonitor物件從哪來？釋放鎖時是將cxq中的元素移動到EntryList的尾部還是頭部？notfiy時，是將ObjectWaiter移動到EntryList的尾部還是頭部？
關于具體的細節，會在重量級鎖的文章中分析，
3.輕量級鎖
JVM的開發者發現在很多情況下，在Java程式運行時，同步塊中的代碼都是不存在競爭的，不同的執行緒交替的執行同步塊中的代碼，這種情況下，用重量級鎖是沒必要的，因此JVM引入了輕量級鎖的概念，
執行緒在執行同步塊之前，JVM會先在當前的執行緒的堆疊幀中創建一個Lock Record，其包括一個用于存盤物件頭中的 mark word（官方稱之為Displaced Mark Word）以及一個指向物件的指標，下圖右邊的部分就是一個Lock Record，
加鎖程序：
1.在執行緒堆疊中創建一個Lock Record，將其obj（即上圖的Object reference）欄位指向鎖物件，
2.直接通過CAS指令將Lock Record的地址存盤在物件頭的mark word中，如果物件處于無鎖狀態則修改成功，代表該執行緒獲得了輕量級鎖，如果失敗，進入到步驟3，
3.如果是當前執行緒已經持有該鎖了，代表這是一次鎖重入，設定Lock Record第一部分（Displaced Mark Word）為null，起到了一個重入計數器的作用，然后結束，
4.走到這一步說明發生了競爭，需要膨脹為重量級鎖，
解鎖程序：
1.遍歷執行緒堆疊,找到所有obj欄位等于當前鎖物件的Lock Record，
2.如果Lock Record的Displaced Mark Word為null，代表這是一次重入，將obj設定為null后continue，
3.如果Lock Record的Displaced Mark Word不為null，則利用CAS指令將物件頭的mark word恢復成為Displaced Mark Word，如果成功，則continue，否則膨脹為重量級鎖，
4.偏向鎖
Java是支持多執行緒的語言，因此在很多二方包、基礎庫中為了保證代碼在多執行緒的情況下也能正常運行，也就是我們常說的執行緒安全，都會加入如synchronized這樣的同步語意，但是在應用在實際運行時，很可能只有一個執行緒會呼叫相關同步方法，比如下面這個demo：
import java.util.ArrayList;
import java.util.List;
public class SyncDemo1 {
public static void main(String[] args) {
SyncDemo1 syncDemo1 = new SyncDemo1();
for (int i = 0; i < 100; i++) {
syncDemo1.addString("test:" + i);
}
}
private List<String> list = new ArrayList<>();
public synchronized void addString(String s) {
list.add(s);
}
}
在這個demo中為了保證對list操縱時執行緒安全，對addString方法加了synchronized的修飾，但實際使用時卻只有一個執行緒呼叫到該方法，對于輕量級鎖而言，每次呼叫addString時，加鎖解鎖都有一個CAS操作；對于重量級鎖而言，加鎖也會有一個或多個CAS操作（這里的’一個‘、’多個‘數量詞只是針對該demo，并不適用于所有場景），
在JDK1.6中為了提高一個物件在一段很長的時間內都只被一個執行緒用做鎖物件場景下的性能，引入了偏向鎖，在第一次獲得鎖時，會有一個CAS操作，之后該執行緒再獲取鎖，只會執行幾個簡單的命令，而不是開銷相對較大的CAS命令，我們來看看偏向鎖是如何做的，
物件創建
當JVM啟用了偏向鎖模式（1.6以上默認開啟），當新創建一個物件的時候，如果該物件所屬的class沒有關閉偏向鎖模式（什么時候會關閉一個class的偏向模式下文會說，默認所有class的偏向模式都是是開啟的），那新創建物件的mark word將是可偏向狀態，此時mark word中的thread id（參見上文偏向狀態下的mark word格式）為0，表示未偏向任何執行緒，也叫做匿名偏向(anonymously biased)，
加鎖程序
case 1：當該物件第一次被執行緒獲得鎖的時候，發現是匿名偏向狀態，則會用CAS指令，將mark word中的thread id由0改成當前執行緒Id，如果成功，則代表獲得了偏向鎖，繼續執行同步塊中的代碼，否則，將偏向鎖撤銷，升級為輕量級鎖，
case 2：當被偏向的執行緒再次進入同步塊時，發現鎖物件偏向的就是當前執行緒，在通過一些額外的檢查后（細節見后面的文章），會往當前執行緒的堆疊中添加一條Displaced Mark Word為空的Lock Record中，然后繼續執行同步塊的代碼，因為操縱的是執行緒私有的堆疊，因此不需要用到CAS指令；由此可見偏向鎖模式下，當被偏向的執行緒再次嘗試獲得鎖時，僅僅進行幾個簡單的操作就可以了，在這種情況下，synchronized關鍵字帶來的性能開銷基本可以忽略，
case 3.當其他執行緒進入同步塊時，發現已經有偏向的執行緒了，則會進入到撤銷偏向鎖的邏輯里，一般來說，會在safepoint中去查看偏向的執行緒是否還存活，如果存活且還在同步塊中則將鎖升級為輕量級鎖，原偏向的執行緒繼續擁有鎖，當前執行緒則走入到鎖升級的邏輯里；如果偏向的執行緒已經不存活或者不在同步塊中，則將物件頭的mark word改為無鎖狀態（unlocked），之后再升級為輕量級鎖，
由此可見，偏向鎖升級的時機為：當鎖已經發生偏向后，只要有另一個執行緒嘗試獲得偏向鎖，則該偏向鎖就會升級成輕量級鎖，當然這個說法不絕對，因為還有批量重偏向這一機制，
解鎖程序
當有其他執行緒嘗試獲得鎖時，是根據遍歷偏向執行緒的lock record來確定該執行緒是否還在執行同步塊中的代碼，因此偏向鎖的解鎖很簡單，僅僅將堆疊中的最近一條lock record的obj欄位設定為null，需要注意的是，偏向鎖的解鎖步驟中并不會修改物件頭中的thread id，
下圖展示了鎖狀態的轉換流程：
另外，偏向鎖默認不是立即就啟動的，在程式啟動后，通常有幾秒的延遲，可以通過命令 -XX:BiasedLockingStartupDelay=0來關閉延遲，
批量重偏向與撤銷
從上文偏向鎖的加鎖解鎖程序中可以看出，當只有一個執行緒反復進入同步塊時，偏向鎖帶來的性能開銷基本可以忽略，但是當有其他執行緒嘗試獲得鎖時，就需要等到safe point時將偏向鎖撤銷為無鎖狀態或升級為輕量級/重量級鎖，safe point這個詞我們在GC中經常會提到，其代表了一個狀態，在該狀態下所有執行緒都是暫停的（大概這么個意思），詳細可以看這篇文章，總之，偏向鎖的撤銷是有一定成本的，如果說運行時的場景本身存在多執行緒競爭的，那偏向鎖的存在不僅不能提高性能，而且會導致性能下降，因此，JVM中增加了一種批量重偏向/撤銷的機制，
https://blog.csdn.net/ITer_ZC/article/details/41892567
存在如下兩種情況：（見官方論文第4小節）:
https://www.oracle.com/technetwork/java/biasedlocking-oopsla2006-wp-149958.pdf
1.一個執行緒創建了大量物件并執行了初始的同步操作，之后在另一個執行緒中將這些物件作為鎖進行之后的操作，這種case下，會導致大量的偏向鎖撤銷操作，
2.存在明顯多執行緒競爭的場景下使用偏向鎖是不合適的，例如生產者/消費者佇列，
批量重偏向（bulk rebias）機制是為了解決第一種場景，批量撤銷（bulk revoke）則是為了解決第二種場景，
其做法是：以class為單位，為每個class維護一個偏向鎖撤銷計數器，每一次該class的物件發生偏向撤銷操作時，該計數器+1，當這個值達到重偏向閾值（默認20）時，JVM就認為該class的偏向鎖有問題，因此會進行批量重偏向，每個class物件會有一個對應的epoch欄位，每個處于偏向鎖狀態物件的mark word中也有該欄位，其初始值為創建該物件時，class中的epoch的值，
每次發生批量重偏向時，就將該值+1，同時遍歷JVM中所有執行緒的堆疊，找到該class所有正處于加鎖狀態的偏向鎖，將其epoch欄位改為新值，下次獲得鎖時，發現當前物件的epoch值和class的epoch不相等，那就算當前已經偏向了其他執行緒，也不會執行撤銷操作，而是直接通過CAS操作將其mark word的Thread Id 改成當前執行緒Id，
當達到重偏向閾值后，假設該class計數器繼續增長，當其達到批量撤銷的閾值后（默認40），JVM就認為該class的使用場景存在多執行緒競爭，會標記該class為不可偏向，之后，對于該class的鎖，直接走輕量級鎖的邏輯，
三、總結
Java中的synchronized有偏向鎖、輕量級鎖、重量級鎖三種形式，分別對應了鎖只被一個執行緒持有、不同執行緒交替持有鎖、多執行緒競爭鎖三種情況，當條件不滿足時，鎖會按偏向鎖->輕量級鎖->重量級鎖 的順序升級，
JVM種的鎖也是能降級的，只不過條件很苛刻，不在我們討論范圍之內，該篇文章主要是對Java的synchronized做個基本介紹，后文會有更詳細的分析，另外，關注公眾號Java技術堆疊，在后臺回復：面試，可以獲取我整理的 Java 系列面試題和答案，非常齊全，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什么新語法？
4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/297005.html
標籤：Java
上一篇：JAVA8 Stream學習