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

阿新 • • 發佈：2020-12-07

Java 15 廢棄偏向鎖

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

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

偏向鎖是 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 實現的。
偏向鎖已經被廢棄了。

參考

https://juejin.cn/post/6844903918653145102#heading-13
極客時間：多執行緒之鎖優化（上）：深入瞭解Synchronized同步鎖的優化方法

公眾號

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

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