偏向鎖原理及其實戰

偏向鎖主要用來解決無競爭下鎖性能問題，在實際場景中，如果一個同步代碼塊（方法）沒有多個線程競爭，而且總是有一個線程多次重入獲取鎖，并且線程每次還有阻塞線程，更改線程狀態為運行狀態等操作，那么此時相對于CPU是一種資源浪費，為了解決這個問題，就引入了偏向鎖

1.偏向鎖原理

偏向鎖原理：

1. 當一個線程獲取了一個對象的鎖時，JVM會將該對象的鎖標記位設置為01，偏向位設置為1，表示該對象進入了偏向鎖狀態。

2. JVM會使用CAS（Compare and Swap）操作將獲取鎖的線程ID記錄在對象的Mark Word中，如果CAS操作失敗，說明有其他線程競爭獲取鎖。

3. 當其他線程嘗試獲取該對象的鎖時，JVM會檢查對象的鎖標記位和偏向位。如果鎖標記位為01且偏向位為1，表示對象處于偏向鎖狀態，并且有線程ID記錄在Mark Word中。

4. 如果嘗試獲取偏向鎖的線程ID與Mark Word中記錄的線程ID相同，說明該線程仍然是獲取鎖的線程，可以直接進入同步代碼塊，無需使用CAS操作。

5. 如果嘗試獲取偏向鎖的線程ID與Mark Word中記錄的線程ID不同，說明有其他線程競爭鎖，此時偏向鎖會自動升級為輕量級鎖狀態。

偏向鎖的引入主要是為了優化無競爭情況下的鎖性能。在無競爭的情況下，偏向鎖可以避免多余的同步操作，從而提高程序的性能。然而，由于偏向鎖需要記錄線程ID并使用CAS操作，會引入一定的額外開銷。因此，JVM會延遲啟用偏向鎖，只對一定時間后創建的對象進行偏向鎖的開啟。

雖然JVM默認開啟偏向鎖，但是延時 4s 開啟，程序創建對象的時候并不會開啟偏向鎖， 4s后創建的對象才會開啟偏向鎖。

需要注意的是，偏向鎖并不適用于具有競爭的情況，當存在多個線程競爭同一個對象的鎖時，偏向鎖會自動升級為輕量級鎖或重量級鎖，以保證線程的互斥訪問和數據一致性。

2.偏向鎖案例代碼演示

2.1.偏向鎖案例代碼

注意 新版的JDK可能默認是禁用偏向鎖的 ，所以需要再JVM啟動參數上添加 開啟偏向鎖的相關代碼

-XX:+UseBiasedLocking

/*** 偏向鎖*/
public class BiasedLockDemo {private static final Logger log = LoggerFactory.getLogger(BiasedLockDemo.class);@Test@DisplayName("偏向鎖測試")public void test() {log.error("JVM詳細信息: {}", VM.current().details());// 休眠5sSleepUtil.sleepMillis(5000);// 創建對象MyObjectLock myObjectLock = new MyObjectLock();log.error("無鎖情況下，lock的狀態！");myObjectLock.printLockStatus();SleepUtil.sleepMillis(5000);CountDownLatch latch = new CountDownLatch(1);Runnable runnable = ()->{// 模擬同一個線程多次進入同步代碼塊for (int i = 0; i < 1000; i++) {synchronized (myObjectLock){myObjectLock.increase();if (i == 1000 / 2){log.error("占有鎖情況下！lock狀態！");myObjectLock.printLockStatus();}}SleepUtil.sleepMillis(10);}latch.countDown();};new Thread(runnable,"biased-thread").start();// 等待所有枷鎖線程執行完畢try {latch.await();} catch (InterruptedException e) {throw new RuntimeException(e);}// 等待5s 查看鎖的狀態SleepUtil.sleepMillis(5000);log.error("釋放鎖后鎖的狀態！");myObjectLock.printLockStatus();}
}
class MyObjectLock{private static final Logger log = LoggerFactory.getLogger(MyObjectLock.class);private int count = 0;/*** 打印當前對象的一個狀態*/public void printLockStatus(){log.error(ClassLayout.parseInstance(this).toPrintable());}/*** 將當前共享變量自增*/public void increase(){this.count++;}
}

這里 我們分為三個部分進行說明

2.2.1.無鎖情況下狀態

• 對象頭部分的第一個4字節（OFFSET 0）表示對象的標記字（Mark Word）。在這個結果中，標記字的十六進制表示為05 00 00 00，對應的二進制為00000101 00000000 00000000 00000000。其中，第一個位為偏向鎖標志位，為1表示啟用了偏向鎖。在這個結果中，偏向鎖標志位為1，說明該對象啟用了偏向鎖。
• 其中 d8 f9 09 01 (11011000 11111001 00001001 00000001) (17431000)為其Class Pointer(類對象指針)
• 對象頭部分的第二個4字節（OFFSET 4）和第三個4字節（OFFSET 8）也是對象頭信息。在這個結果中，這兩個字節的值都為0，沒有包含其他重要的標志位信息。
• 接下來的4字節（OFFSET 12）表示MyObjectLock對象中的一個整型字段count。在這個結果中，count字段的值為0。
• 最后，結果顯示了對象的實例大小為16字節，并且沒有內部或外部的空間損失。

2.1.2.偏向鎖狀態

在輸出MyObjectLock實例結構后，等待5s，然后啟動一個線程占用偏向鎖，因為輸出的內容比較多，所以這里選擇了到中間值的時候進行輸出結構。

• 對象頭部分的第一個4字節（OFFSET 0）表示對象的標記字（Mark Word）。在這個結果中，標記字的十六進制表示為05 80 e6 c1，對應的二進制為00000101 10000000 11100110 11000001。其中，第一個位為偏向鎖標志位，為1表示啟用了偏向鎖。在這個結果中，偏向鎖標志位為1，說明該對象啟用了偏向鎖。
• 對象頭部分的第二個4字節（OFFSET 4）和第三個4字節（OFFSET 8）也是對象頭信息。在這個結果中，這兩個字節的值分別為c0 02 00 00和d8 f9 09 01。
• 接下來的4字節（OFFSET 12）表示MyObjectLock對象中的一個整型字段count。在這個結果中，count字段的值為501。
• 最后，結果顯示了對象的實例大小為16字節，并且沒有內部或外部的空間損失。

2.1.3.釋放鎖后的狀態

• 對象頭部分的第一個4字節（OFFSET 0）表示對象的標記字（Mark Word）。在這個結果中，標記字的十六進制表示為05 80 e6 c1，對應的二進制為00000101 10000000 11100110 11000001。其中，第一個位為偏向鎖標志位，為1表示啟用了偏向鎖。在這個結果中，偏向鎖標志位為1，說明該對象啟用了偏向鎖。
• 對象頭部分的第二個4字節（OFFSET 4）和第三個4字節（OFFSET 8）也是對象頭信息。在這個結果中，這兩個字節的值分別為c0 02 00 00和d8 f9 09 01。
• 接下來的4字節（OFFSET 12）表示MyObjectLock對象中的一個整型字段count。在這個結果中，count字段的值為1000。
• 最后，結果顯示了對象的實例大小為16字節，并且沒有內部或外部的空間損失。

2.2.偏向鎖的膨脹和撤銷

假如有多個線程來競爭偏向鎖，此對象鎖就不會有所偏向了，其他線程發現偏向鎖并不是偏向自己，就說明存在了競爭，會嘗試撤銷偏向鎖，然后膨脹到輕量級鎖。

2.2.1.偏向鎖撤銷的條件

• 多個線程存在競爭
• 調用偏向鎖對象的obj的obj.hashCode或者System.indentityHsahCode()方法計算對象的hash碼，偏向鎖將會被撤銷。
  • 因為一個對象的哈希碼只會生成一次，并且保存在Mark Word中，偏向鎖的Mark Word 已經保存了線程ID,沒有其他地方在保存哈希碼了，所以只能撤銷偏向鎖
  • 輕量級鎖會在棧幀的Lock Record（鎖記錄）中記錄哈希碼
  • 重量級鎖會在監視器中記錄哈希碼

2.2.2.偏向鎖的撤銷

偏向鎖的撤銷的開銷花費是挺大的，其大概過程如下

1. JVM需要等待一個全局安全點，當JVM到達全局安全點后，所有的用戶線程都是暫停的，當前持有偏向鎖的用戶線程也是暫停的。
2. 遍歷線程的棧幀，檢查是否存在鎖記錄，如果存在鎖記錄，那么就清空鎖記錄，使其變成無鎖的狀態，并修復鎖記錄指向的線程ID，清除其線程ID
3. 將當前鎖升級（或碰撞）成輕量級鎖，少數場景直接升級為重量級鎖
4. 喚醒當前線程

2.2.3.偏向鎖的膨脹

如果偏向鎖被占據，那么第二個線程爭搶這個對象，因為偏向鎖不會主動釋放，所以第二個線程可以看到內置鎖的偏向狀態，這時JVM會檢查原來持有該偏向鎖線程是否存活，如果掛了，那么將該對象變為無鎖狀態，重新偏向，如果沒掛，就發生競爭，進行膨脹。

1. 當一個線程嘗試獲取一個偏向鎖時，如果該鎖的標記字（Mark Word）指向的線程ID與當前線程ID不一致，表示存在競爭，此時偏向鎖需要膨脹。
2. JVM會將對象的標記字從偏向鎖狀態修改為輕量級鎖狀態。這個過程稱為鎖的膨脹。
3. 膨脹為輕量級鎖的過程包括以下步驟：
   • JVM會嘗試使用CAS（Compare and Swap）操作將對象的標記字修改為指向鎖記錄的指針，同時更新鎖記錄中的線程ID為當前線程ID。
   • 如果CAS操作成功，表示膨脹為輕量級鎖成功。
   • 如果CAS操作失敗，說明存在競爭，此時會進一步膨脹為重量級鎖。
4. 膨脹為重量級鎖的過程包括以下步驟：
   • JVM會在堆中分配一個監視器（Monitor）對象，用于管理鎖的狀態。
   • 將對象的標記字指向該監視器對象，并將鎖記錄中的線程ID修改為0。
   • 此時，鎖的狀態變為重量級鎖。

2.3.全局安全點原理和偏向鎖撤銷性能問題

2.3.1.全局安全點介紹

在Java虛擬機（JVM）中，全局安全點（Global Safepoint）是一個重要的概念，用于確保在某個特定的時間點，所有的線程都處于安全狀態，可以被安全地中斷。全局安全點的引入是為了支持一些關鍵操作，例如線程停止、垃圾回收等。

實現全局安全點的核心思想是在代碼的特定位置插入安全點檢查。安全點檢查是一段特殊的機器碼指令，用于判斷當前線程是否到達安全點。當一個線程到達安全點時，它會被停止，并且進一步的操作需要等待其他線程也到達安全點。只有當所有線程都到達安全點時，JVM才能執行需要線程處于安全狀態的操作。

全局安全點的引入是為了解決并發線程訪問共享數據的一致性問題。在偏向鎖撤銷的過程中，JVM需要等待全局安全點的到來，以確保所有的線程都被暫停，包括持有偏向鎖的線程。只有當所有線程都暫停時，JVM才能安全地撤銷偏向鎖，并進行相應的操作。

全局安全點的實現機制主要包括以下幾個方面：

1. 安全點的選定：
   JVM會選擇一些合適的位置作為安全點，通常是在方法調用、循環跳轉等代碼塊的末尾。這些位置被認為是安全點，因為在這些位置上線程處于安全狀態，可以被安全地中斷。安全點的選定通常是通過靜態分析和動態檢測相結合的方式來確定的。
2. 安全點的設置：
   JVM會在代碼中插入安全點檢查的指令，用于檢查當前線程是否到達安全點。這些指令通常是無操作（NOP）指令或輕量級的計算指令，不會對程序的語義產生影響。當線程執行到安全點檢查指令時，會檢查當前線程是否到達安全點，如果沒有到達則會等待其他線程也到達安全點。
3. 安全點的等待：
   當一個線程到達安全點時，它會被停止，并且進一步的操作需要等待其他線程也到達安全點。只有當所有線程都到達安全點時，JVM才能執行需要線程處于安全狀態的操作。線程的等待是通過自旋等待或掛起等待的方式來實現的。
4. 安全點的恢復：
   當所有線程都到達安全點后，JVM可以執行需要線程處于安全狀態的操作。完成操作后，JVM會恢復線程的執行，使其繼續執行下去。恢復線程的執行可以通過喚醒等待線程或者設置標記等方式來實現。

2.3.1 偏向鎖撤銷性能問題

偏向鎖撤銷的過程相對于偏向鎖的獲取和釋放而言，具有較高的開銷。這是因為偏向鎖撤銷需要等待全局安全點，并進行一系列的操作來撤銷偏向鎖。這些額外的操作會增加系統開銷，影響性能。

偏向鎖撤銷的性能問題主要體現在以下幾個方面：

1. 全局安全點的等待時間：在偏向鎖撤銷過程中，JVM需要等待全局安全點的到來。這會導致線程在等待期間無法執行其他有用的工作，從而造成性能損失。
2. 線程棧幀的遍歷和修改：在偏向鎖撤銷過程中，JVM需要遍歷線程的棧幀，檢查是否存在鎖記錄，并對鎖記錄進行修改。這涉及到線程狀態的切換和尋址操作，會增加額外的開銷。
3. 鎖的狀態轉換：偏向鎖撤銷后，鎖需要進行狀態轉換，通常是升級為輕量級鎖或重量級鎖。這種狀態轉換涉及到鎖的標記字和鎖記錄的修改，可能需要進行CAS（Compare and Swap）操作，增加了額外的開銷。

為了減少偏向鎖撤銷的性能開銷，可以采取一些優化措施，例如調整全局安全點的觸發頻率、優化線程棧幀的遍歷算法，以及采用延遲偏向鎖撤銷等策略。這些優化措施可以提高偏向鎖的性能并減少性能損失。然而，需要注意的是，在特定的應用場景下，偏向鎖的撤銷可能仍然會帶來一定的性能開銷。因此，在設計和使用偏向鎖時需要綜合考慮性能與應用需求之間的平衡。

對于高并發應用來說，一般建議關閉偏向鎖(JDK9之后，偏向鎖默認是關閉的)

-XX:-UseBiasedLocking