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 實作的，
偏向鎖已經被廢棄了，

參考

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

公眾號

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

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/231288.html

標籤：Java

上一篇：@validate或@valid注解進行資料校驗的解決方案

下一篇：【JAVA并發第一篇】Java的行程與執行緒

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