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

  • 2020 年 12 月 7 日
  • 筆記

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

說明：部分參考自 //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. //juejin.cn/post/6844903918653145102#heading-13
  2. 極客時間：多執行緒之鎖優化（上）：深入了解Synchronized同步鎖的優化方法

公眾號

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

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

VirMach 便宜 VPS

QNews

QNews