# Java 15 廢棄偏向鎖 JDK 15已經在2020年9月15日釋出,詳情見 [JDK 15 官方計劃](https://openjdk.java.net/projects/jdk/15/)。其中有一項更新是`廢棄偏向鎖`，官方的詳細說明在：[JEP 374: Disable and Deprecate Biased Locking](https://openjdk.java.net/jeps/374)。 具體的說明見：[JDK 15已釋出，你所要知道的都在這裡！](https://github.com/LjyYano/Thinking_in_Java_MindMapping/blob/master/2020-09-19%20JDK%2015%E5%B7%B2%E5%8F%91%E5%B8%83%EF%BC%8C%E4%BD%A0%E6%89%80%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84%E9%83%BD%E5%9C%A8%E8%BF%99%E9%87%8C%EF%BC%81.md) ## 當時為什麼要引入偏向鎖？ 偏向鎖是 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 的基礎使用就不列舉了，它可以修飾方法，也可以修飾程式碼塊。  ## 修飾方法 ```java public synchronized void syncMethod() { System.out.println("syncMethod"); } ``` 反編譯的結果如下圖所示，可以看到 syncMethod 方法的 flag 包含 `ACC_SYNCHRONIZED` 標誌位。  ## 修飾程式碼塊 ```java 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 [官方的定義](https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.11.10) 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 類，這個類有如下的初始化方法： ```java 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 專案](https://github.com/LjyYano/Thinking_in_Java_MindMapping)中，歡迎大家 star！ ![](https://img2020.cnblogs.com/other/633265/202012/633265-20201207184236019-251409