由Java 15廢棄偏向鎖，談談Java Synchronized 的鎖機制

Java 15 廢棄偏向鎖

JDK 15已經在2020年9月15日發布,詳情見 JDK 15 官方計划。其中有一項更新是廢棄偏向鎖，官方的詳細說明在：JEP 374: Disable and Deprecate Biased Locking。

具體的說明見：JDK 15已發布，你所要知道的都在這里！

當時為什么要引入偏向鎖？

偏向鎖是 HotSpot 虛擬機使用的一項優化技術，能夠減少無競爭鎖定時的開銷。偏向鎖的目的是假定 monitor 一直由某個特定線程持有，直到另一個線程嘗試獲取它，這樣就可以避免獲取 monitor 時執行 cas 的原子操作。monitor 首次鎖定時偏向該線程，這樣就可以避免同一對象的后續同步操作步驟需要原子指令。從歷史上看，偏向鎖使得 JVM 的性能得到了顯著改善。

現在為什么又要廢棄偏向鎖？

但是過去看到的性能提升，在現在看來已經不那么明顯了。受益於偏向鎖的應用程序，往往是使用了早期 Java 集合 API的程序（JDK 1.1），這些 API（Hasttable 和 Vector） 每次訪問時都進行同步。JDK 1.2 引入了針對單線程場景的非同步集合（HashMap 和 ArrayList），JDK 1.5 針對多線程場景推出了性能更高的並發數據結構。這意味着如果代碼更新為使用較新的類，由於不必要同步而受益於偏向鎖的應用程序，可能會看到很大的性能提高。此外，圍繞線程池隊列和工作線程構建的應用程序，性能通常在禁用偏向鎖的情況下變得更好。

偏向鎖為同步系統引入了許多復雜的代碼，並且對 HotSpot 的其他組件產生了影響。這種復雜性已經成為理解代碼的障礙，也阻礙了對同步系統進行重構。因此，我們希望禁用、廢棄並最終刪除偏向鎖。

思考

現在很多面試題都是講述 CMS、G1 這些垃圾回收的原理，但是實際上官方在 Java 11 就已經推出了 ZGC，號稱 GC 方向的未來。對於鎖的原理，其實 Java 8 的知識也需要更新了，畢竟技術一直在迭代，還是要不斷更新自己的知識……學無止境……

話說回來偏向鎖產生的原因，很大程度上是 Java 一直在兼容以前的程序，即使到了 Java 15，以前的 Hasttable 和 Vector 這種老古董性能差的類庫也不會刪除。這樣做的好處很明顯，但是壞處也很明顯，Java 要一直兼容這些代碼，甚至影響 JVM 的實現。

本篇文章系統整理下 Java 的鎖機制以及演進過程。

鎖的發展過程

在 JDK 1.5 之前，Java 是依靠 Synchronized 關鍵字實現鎖功能來做到這點的。Synchronized 是 JVM 實現的一種內置鎖，鎖的獲取和釋放是由 JVM 隱式實現。

到了 JDK 1.5 版本，並發包中新增了 Lock 接口來實現鎖功能，它提供了與Synchronized 關鍵字類似的同步功能，只是在使用時需要顯示獲取和釋放鎖。

Lock 同步鎖是基於 Java 實現的，而 Synchronized 是基於底層操作系統的 Mutex Lock 實現的，每次獲取和釋放鎖操作都會帶來用戶態和內核態的切換，從而增加系統性能開銷。因此，在鎖競爭激烈的情況下，Synchronized同步鎖在性能上就表現得非常糟糕，它也常被大家稱為重量級鎖。

特別是在單個線程重復申請鎖的情況下，JDK1.5 版本的 Synchronized 鎖性能要比 Lock 的性能差很多。

到了 JDK 1.6 版本之后，Java 對 Synchronized 同步鎖做了充分的優化，甚至在某些場景下，它的性能已經超越了 Lock 同步鎖。

Synchronized

說明：部分參考自 https://juejin.cn/post/6844903918653145102

Synchronized 的基礎使用就不列舉了，它可以修飾方法，也可以修飾代碼塊。

修飾方法

public synchronized void syncMethod() {
    System.out.println("syncMethod");
}

反編譯的結果如下圖所示，可以看到 syncMethod 方法的 flag 包含 ACC_SYNCHRONIZED 標志位。

修飾代碼塊

public void syncCode() {
    synchronized (SynchronizedTest.class) {
        System.out.println("syncCode");
    }
}

反編譯的結果如下圖所示，可以看到 syncCode 方法中包含 monitorenter 和 monitorexit 兩個 JVM 指令。

JVM 同步指令分析

monitorenter

直接看官方的定義：

主要的意思是說：

每個對象都與一個 monitor 相關聯。當且僅當 monitor 對象有一個所有者時才會被鎖定。執行 monitorenter 的線程試圖獲得與 objectref 關聯的 monitor 的所有權，如下所示:

• 若與 objectref 相關聯的 monitor 計數為 0，線程進入 monitor 並設置 monitor 計數為 1，這個線程成為這個 monitor 的擁有者。
• 如果該線程已經擁有與 objectref 關聯的 monitor，則該線程重新進入 monitor，並增加 monitor 的計數。
• 如果另一個線程已經擁有與 objectref 關聯的 monitor，則該線程將阻塞，直到 monitor 的計數為零，該線程才會再次嘗試獲得 monitor 的所有權。

monitorexit

直接看官方的定義：

主要的意思是說：

• 執行 monitorexit 的線程必須是與 objectref 引用的實例相關聯的 monitor 的所有者。
• 線程將與 objectref 關聯的 monitor 計數減一。如果計數為 0，則線程退出並釋放這個 monitor。其他因為該 monitor 阻塞的線程可以嘗試獲取該 monitor。

ACC_SYNCHRONIZED

官方的定義

JVM 對於方法級別的同步是隱式的，是方法調用和返回值的一部分。同步方法在運行時常量池的 method_info 結構中由 ACC_SYNCHRONIZED 標志來區分，它由方法調用指令來檢查。當調用設置了 ACC_SYNCHRONIZED 標志位的方法時，調用線程會獲取 monitor，調用方法本身，再退出 monitor。

操作系統的管程（Monitor）

管程是一種在信號量機制上進行改進的並發編程模型。

管程模型

管程的組成如下：

• 共享變量
• 入口等待隊列
• 一個鎖：控制整個管程代碼的互斥訪問
• 0 個或多個條件變量：每個條件變量都包含一個自己的等待隊列，以及相應的出/入隊操作

ObjectMonitor

JVM 中的同步就是基於進入和退出管程（Monitor）對象實現的。每個對象實例都會有一個 Monitor，Monitor 可以和對象一起創建、銷毀。Monitor 是由 ObjectMonitor 實現，而 ObjectMonitor 是由 C++ 的 ObjectMonitor.hpp 文件實現，如下所示：

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 ;
}

本文使用的是 Java 11，其中有 sun.jvm.hotspot.runtime.ObjectMonitor 類，這個類有如下的初始化方法：

private static synchronized void initialize(TypeDataBase db) throws WrongTypeException {
    heap = VM.getVM().getObjectHeap();
    Type type  = db.lookupType("ObjectMonitor");
    sun.jvm.hotspot.types.Field f = type.getField("_header");
    headerFieldOffset = f.getOffset();
    f = type.getField("_object");
    objectFieldOffset = f.getOffset();
    f = type.getField("_owner");
    ownerFieldOffset = f.getOffset();
    f = type.getField("FreeNext");
    FreeNextFieldOffset = f.getOffset();
    countField  = type.getJIntField("_count");
    waitersField = type.getJIntField("_waiters");
    recursionsField = type.getCIntegerField("_recursions");
}

可以和 C++ 的 ObjectMonitor.hpp 的結構對應上，如果查看 initialize 方法的調用鏈，能夠發現很多 JVM 的內部原理，本篇文章限於篇幅和內容原因，不去詳細敘述了。

工作原理

Java Monitor 的工作原理如圖：

當多個線程同時訪問一段同步代碼時，多個線程會先被存放在 EntryList 集合中，處於 block 狀態的線程，都會被加入到該 列表。接下來當線程獲取到對象的 Monitor時，Monitor 是依靠底層操作系統的 Mutex Lock 來實現互斥的，線程申請 Mutex 成功，則持有該 Mutex，其它線程將無法獲取到該 Mutex。

如果線程調用 wait() 方法，就會釋放當前持有的 Mutex，並且該線程會進入 WaitSet 集合中，等待下一次被喚醒。如果當前線程順利執行完方法，也將釋放 Mutex。

Monitor 依賴於底層操作系統的實現，存在用戶態和內核態的轉換，所以增加了性能開銷。但是程序中使用了 Synchronized 關鍵字，程序也不全會使用 Monitor，因為 JVM 對 Synchronized 的實現也有 3 種：偏向鎖、輕量級鎖、重量級鎖。

鎖升級

為了提升性能，JDK 1.6 引入了偏向鎖（就是這個已經被 JDK 15 廢棄了）、輕量級鎖、重量級鎖概念，來減少鎖競爭帶來的上下文切換，而正是新增的 Java 對象頭實現了鎖升級功能。

Java 對象頭

那么 Java 對象頭又是什么？在 JDK 1.6 中，對象實例分為：

• 對象頭
  • Mark Word
  • 指向類的指針
  • 數組長度
• 實例數據
• 對齊填充

其中 Mark Word 記錄了對象和鎖有關的信息，在 64 位 JVM 中的長度是 64 位，具體信息如下圖所示：

偏向鎖

為什么要有偏向鎖呢？偏向鎖主要用來優化同一線程多次申請同一個鎖的競爭。可能大部分時間一個鎖都是被一個線程持有和競爭。假如一個鎖被線程 A 持有，后釋放；接下來又被線程 A 持有、釋放……如果使用 monitor，則每次都會發生用戶態和內核態的切換，性能低下。

作用：當一個線程再次訪問這個同步代碼或方法時，該線程只需去對象頭的 Mark Word 判斷是否有偏向鎖指向它的 ID，無需再進入 Monitor 去競爭對象了。當對象被當做同步鎖並有一個線程搶到了鎖時，鎖標志位還是 01，“是否偏向鎖”標志位設置為 1，並且記錄搶到鎖的線程 ID，表示進入偏向鎖狀態。

一旦出現其它線程競爭鎖資源，偏向鎖就會被撤銷。撤銷時機是在全局安全點，暫停持有該鎖的線程，同時堅持該線程是否還在執行該方法。是則升級鎖；不是則被其它線程搶占。

在高並發場景下，大量線程同時競爭同一個鎖資源，偏向鎖會被撤銷，發生 stop the world后，開啟偏向鎖會帶來更大的性能開銷（這就是 Java 15 取消和禁用偏向鎖的原因），可以通過添加 JVM 參數關閉偏向鎖：

-XX:-UseBiasedLocking //關閉偏向鎖（默認打開）

或

-XX:+UseHeavyMonitors  //設置重量級鎖

輕量級鎖

如果另一線程競爭鎖，由於這個鎖已經是偏向鎖，則判斷對象頭的 Mark Word 的線程 ID 不是自己的線程 ID，就會進行 CAS 操作獲取鎖：

• 成功，直接替換 Mark Word 中的線程 ID 為當前線程 ID，該鎖會保持偏向鎖。
• 失敗，標識鎖有競爭，偏向鎖會升級為輕量級鎖。

輕量級鎖的適用范圍：線程交替執行同步塊，大部分鎖在整個同步周期內部存在場館時間的競爭。

自旋鎖與重量級鎖

輕量級鎖的 CAS 搶鎖失敗，線程會掛起阻塞。若正在持有鎖的線程在很短的時間內釋放鎖，那么剛剛進入阻塞狀態的線程又要重新申請鎖資源。

如果線程持有鎖的時間不長，則未獲取到鎖的線程可以不斷嘗試獲取鎖，避免線程被掛起阻塞。JDK 1.7 開始，自旋鎖默認開啟，自旋次數又 JVM 配置決定。

自旋鎖重試之后如果搶鎖依然失敗，同步鎖就會升級至重量級鎖，鎖標志位改為 10。在這個狀態下，未搶到鎖的線程都會進入 Monitor，之后會被阻塞在 _WaitSet 隊列中。

在高負載、高並發的場景下，可以通過設置 JVM 參數來關閉自旋鎖，優化性能：

-XX:-UseSpinning //參數關閉自旋鎖優化(默認打開) 
-XX:PreBlockSpin //參數修改默認的自旋次數。JDK1.7后，去掉此參數，由jvm控制

再深入分析

鎖究竟鎖的是什么呢？又是誰鎖的呢？

當多個線程都要執行某個同步方法時，只有一個線程可以獲取到鎖，然后其余線程都在阻塞等待。所謂的“鎖”動作，就是讓其余的線程阻塞等待；那 Monitor 是何時生成的呢？我個人覺得應該是在多個線程同時請求的時候，生成重量級鎖，一個對象才會跟一個 Monitor 相關聯。

那其余的被阻塞的線程是在哪里記錄的呢？就是在這個 Monitor 對象中，而這個 Monitor 對象就在對象頭中。（如果不對，歡迎大家留言討論~）

鎖優化

Synchronized 只在 JDK 1.6 以前性能才很差，因為這之前的 JVM 實現都是重量級鎖，直接調用 ObjectMonitor 的 enter 和 exit。從 JDK 1.6 開始，HotSpot 虛擬機就增加了上述所說的幾種優化：

• 偏向鎖
• 輕量級鎖
• 自旋鎖

其余還有：

• 適應性自旋
• 鎖消除
• 鎖粗化

鎖消除

這屬於編譯器對鎖的優化，JIT 編譯器在動態編譯同步塊時，會使用逃逸分析技術，判斷同步塊的鎖對象是否只能被一個對象訪問，沒有發布到其它線程。

如果確認沒有“逃逸”，JIT 編譯器就不會生成 Synchronized 對應的鎖申請和釋放的機器碼，就消除了鎖的使用。

鎖粗化

JIT 編譯器動態編譯時，如果發現幾個相鄰的同步塊使用的是同一個鎖實例，那么 JIT 編譯器將會把這幾個同步塊合並為一個大的同步塊，從而避免一個線程“反復申請、釋放同一個鎖“所帶來的性能開銷。

減小鎖粒度

我們在代碼實現時，盡量減少鎖粒度，也能夠優化鎖競爭。

總結

• 其實現在 Synchronized 的性能並不差，偏向鎖、輕量級鎖並不會從用戶態到內核態的切換；只有在競爭十分激烈的時候，才會升級到重量級鎖。
• Synchronized 的鎖是由 JVM 實現的。
• 偏向鎖已經被廢棄了。

參考

1. https://juejin.cn/post/6844903918653145102#heading-13
2. 極客時間：多線程之鎖優化（上）：深入了解Synchronized同步鎖的優化方法

公眾號

coding 筆記、點滴記錄，以后的文章也會同步到公眾號（Coding Insight）中，希望大家關注^_

代碼和思維導圖在 GitHub 項目中，歡迎大家 star！