@[toc] # 前言 上一篇分析了優化後的synchronized在不同場景下物件頭中的表現形式，還記得那個結論嗎？**當一個執行緒第一次獲取鎖後再去拿鎖就是偏向鎖，如果有別的執行緒和當前執行緒交替執行就膨脹為輕量級鎖，如果發生競爭就會膨脹為重量級鎖**。這句話看起來很簡單，但實際上synhronized的膨脹過程是非常複雜的，有許多場景和細節需要考慮，本篇就對其進行詳細分析。 # 正文 先來看一個案例程式碼： ```java public class TestInflate { static Thread t2; static Thread t3; static Thread t1; static int loopFlag = 19; public static void main(String[] args) throws InterruptedException { //a 沒有執行緒偏向---匿名 101偏向鎖 List list = new ArrayList<>(); t1 = new Thread() { @Override public void run() { for (int i = 0; i < loopFlag; i++) { A a = new A(); list.add(a); synchronized (a) { log.debug(i + " " + ClassLayout.parseInstance(a).toPrintableTest(a)); } } log.debug("========t2================="); LockSupport.unpark(t2); } }; t2 = new Thread() { @Override public void run() { LockSupport.park(); for (int i = 0; i < loopFlag; i++) { A a = list.get(i); log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a)); synchronized (a) { log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a)); } log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a)); } log.debug("======t3====================================="); LockSupport.unpark(t3); } }; t3 = new Thread() { @Override public void run() { LockSupport.park(); for (int i = 0; i < loopFlag; i++) { A a = list.get(i); log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a)); synchronized (a) { log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a)); } log.debug(i + " " + ClassLayout.parseInstance(a).toPrintable(a)); } } }; t1.start(); t2.start(); t3.start(); t3.join(); log.debug(ClassLayout.parseInstance(new A()).toPrintable()); } ``` 這裡建立了三個執行緒t1、t2、t3，在t1中建立了loopFlag個物件並依次加鎖，然後放入到list中，t2等待t1執行完成後依次讀取list中物件進行加鎖並列印加鎖前、加鎖後、解鎖後的物件頭，t3和t2相同，只不過需要等待t2執行完才開始執行，最後等三個執行緒執行完成後再新建一個物件並列印物件頭（注意執行該程式碼需要關閉偏向延遲-XX:BiasedLockingStartupDelay=0）。 ## 偏向鎖 偏向鎖沒什麼好演示的，但是在原始碼中獲取偏向鎖是第一步，且邏輯比較多，有以下幾點需要注意： - 是否已經超過偏向延遲指定的時間，若沒有，則只能獲取輕量鎖 - 是否允許偏向 - 如果只有當前執行緒且是第一次則直接獲取偏向鎖（使用class物件中的mark word和執行緒id做"或"操作，得到一個新的header，並通過CAS替換鎖物件頭，替換成功則獲取到偏向鎖，否則進入鎖升級的流程） - 是否呼叫了鎖物件未重寫的hashcode（對應原始碼中的Object#hash或System.identityHashCode()方法），hashcode會佔用物件頭的空間，導致無法偏向 - 執行緒是否交替執行（即當前執行緒ID和物件頭中的執行緒ID不一致），若是交替執行可能獲取到偏向鎖、輕量鎖，細節下文詳細講述。 ## 輕量鎖 首先註釋掉t3，先設定loopFlag=19執行t1和t2，你能猜到列印的物件頭是什麼樣的麼？（為節省篇幅，下文物件頭都只擷取最後8位展示） ```java 15:57:38.579 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 0 00000101 15:57:38.580 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 1 00000101 ...... 15:57:38.582 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 17 00000101 15:57:38.582 [Thread-0] DEBUG cn.dark.ex6.TestInflate - 18 00000101 15:57:38.582 [Thread-0] DEBUG cn.dark.ex6.TestInflate - ========t2================= 15:57:38.582 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000101 15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 10000000 15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000001 15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 1 00000101 15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 1 10000000 15:57:38.583 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 1 00000001 ...... 15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 17 00000101 15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 17 10000000 15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 17 00000001 15:57:38.589 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000101 15:57:38.590 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 10000000 15:57:38.590 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000001 15:57:38.590 [Thread-1] DEBUG cn.dark.ex6.TestInflate - ======t3===================================== 15:57:38.590 [main] DEBUG cn.dark.ex6.TestInflate - cn.dark.entity.A object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5) 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) 2c 6a 01 f8 (00101100 01101010 00000001 11111000) (-134125012) 12 4 (loss due to the next object alignment) ``` t1執行緒不用想，肯定都是101，因為拿到的是偏向鎖，但是t2就和我上一篇說的有點不一樣了。t2加鎖前的狀態和t1解鎖後是一樣的，偏向鎖解鎖不會改變物件頭，接著對其加鎖，判斷當前執行緒id和物件頭中的執行緒id是否相同，由於不相同所以會做**偏向撤銷**（即將狀態修改為001無鎖狀態）並膨脹為**輕量鎖**（實際上物件第一次加鎖時，也有這個判斷，接著會判斷是不是**匿名偏向**，即是不是可偏向模式且第一次加鎖，是則直接獲取偏向鎖），狀態改為00。 需要注意輕量鎖加鎖前會在當前執行緒棧幀中建立一個**無鎖的Lock Record**，加鎖時就會使用CAS操作判斷當前物件頭中的mark word是否和lr中的displaced word相等，由於都是001所以能加鎖成功，之後輕量鎖解鎖只需要將lr中的dr恢復到當前物件頭中（001），這樣下一個執行緒才能對該物件再次加鎖。需要注意雖然輕量鎖解鎖後物件頭是001狀態，但新建的物件依然是預設的101可偏向無鎖狀態，正如上面最後一次列印。 ## 批量重偏向 上面建立的19個物件在膨脹為輕量鎖的時候都會進行**偏向撤銷**，但是撤銷是有效能損耗的，所以JVM設定了一個閾值，當撤銷達到20次的時候就會進行**批量重偏向**，該閾值可通過-XX:BiasedLockingBulkRebiasThreshold=20修改。 將上面程式碼中的loopFlag改為大於19的數列印結果（後面都不再展示t1執行緒的列印結果）： ```java 16:52:02.005 [Thread-0] DEBUG cn.dark.ex6.TestInflate - ========t2================= 16:52:02.005 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000101 16:52:02.005 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00110000 16:52:02.005 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 0 00000001 ...... 16:52:02.011 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000101 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00110000 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 18 00000001 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 19 00000101 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 19 00000101 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 19 00000101 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 20 00000101 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 20 00000101 16:52:02.012 [Thread-1] DEBUG cn.dark.ex6.TestInflate - 20 00000101 16:54:45.035 [main] DEBUG cn.dark.ex6.TestInflate - cn.dark.entity.A object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 01 00 00 (00000101 00000001 00000000 00000000) (261) 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) 2c 6a 01 f8 (00101100 01101010 00000001 11111000) (-134125012) 12 4 (loss due to the next object alignment) ``` 前面19個物件都需要進行撤銷，當達到20時，所有的物件頭都變成了101了，並且偏向當前執行緒t2（這裡需要注意，**批量**指的是當前正被加鎖的所有物件，還沒有加鎖的，即從第21個物件開始都是**逐個**重偏向；另外雖重偏向是先將鎖物件設定為可偏向無鎖模式101，再講執行緒id設定進去），如果此時你列印完整的物件頭出來還會發現**偏向時間戳標誌**設定為了01，即代表過期進行了重偏向。需要注意，這時候新建的物件也是101狀態，且是**重偏向**。 ## 批量撤銷 JVM還有一個引數-XX:BiasedLockingBulkRevokeThreshold=40用來控制**批量撤銷**，即預設當一個**類**累計撤銷達到40次，那麼新建的物件就直接是**無鎖不可偏向**的，因為JVM認為這是程式碼存在了嚴重的問題。 將t3註釋放開，並將loopFlag設定為50，觀察結果： ```java 17:15:46.640 [Thread-1] DEBUG cn.dark.ex6.TestInflate - ======t3===================================== 17:15:46.640 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 0 00000001 17:15:46.640 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 0 11100000 17:15:46.640 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 0 00000001 ...... 17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 18 00000001 17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 18 11100000 17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 18 00000001 17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 19 00000101 17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 19 11100000 17:15:46.644 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 19 00000001 ....... 17:15:46.650 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 39 00000101 17:15:46.650 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 39 11100000 17:15:46.651 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 39 00000001 ...... 17:15:46.652 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 49 00000101 17:15:46.652 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 49 11100000 17:15:46.653 [Thread-2] DEBUG cn.dark.ex6.TestInflate - 49 00000001 OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1) 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) 2c 6a 01 f8 (00101100 01101010 00000001 11111000) (-134125012) 12 4 (loss due to the next object alignment) ``` t3執行緒前面20個物件都是從001加鎖為輕量鎖，所以不用進行撤銷，而t2執行緒從第21個物件開始都是獲取的偏向鎖，所以，t3執行緒就需要從第21個物件開始撤銷，當和其它所有執行緒對該類物件累計撤銷了40次後新建的物件都不能再獲取偏向鎖（這裡博主是直接設定的50個物件，讀者可以設定40個物件來驗證），不過在此之前已經獲取偏向鎖的物件還是要逐個撤銷。 但是系統是長期執行的，可能批量重偏向之後很久才會累計撤銷達到40次，比如一個月、一年甚至更久，這種情況下就沒有必要進行批量撤銷了，因此JVM提供了一個引數-XX:BiasedLockingDecayTime=25000，即預設距上一次批量重偏向超過25000ms後，計數器就會重置為0。下面是JVM關於這一點的原始碼： ```c++ // 當前時間 jlong cur_time = os::javaTimeMillis(); // 該類上一次批量撤銷的時間 jlong last_bulk_revocation_time = k->last_biased_lock_bulk_revocation_time(); // 該類偏向鎖撤銷的次數 int revocation_count = k->biased_lock_revocation_count(); // BiasedLockingBulkRebiasThreshold是重偏向閾值（預設20）， // BiasedLockingBulkRevokeThreshold是批量撤銷閾值（預設40）， // BiasedLockingDecayTime預設25000。 if ((revocation_count >= BiasedLockingBulkRebiasThreshold) && (revocation_count < BiasedLockingBulkRevokeThreshold) && (last_bulk_revocation_time != 0) && (cur_time - last_bulk_revocation_time >= BiasedLockingDecayTime)) { // 重置計數器 k->set_biased_lock_revocation_count(0); revocation_count = 0; } ``` 具體案例很簡單，讀者們可以思考下怎麼驗證這個結論。 ## 重量鎖 由於synchronized是c++語言實現的，實現比較複雜，就不進行詳細的原始碼分析了，下面只是對其實現原理的一個總結。另外重量鎖的實現原理和ReentrantLock的思想是一樣的，讀者們可以對比理解。 當多個執行緒發生競爭的時候，synchronized就會膨脹為重量鎖，這時會建立一個ObjectMoitor物件，這個物件包含了三個由ObjectWaiter物件組成的佇列：**cxq**、**EntryList**、**WaitSet**，以及兩個欄位**owner**和**Read Thread**。cxq和EntryList都是獲取鎖失敗用來儲存等待的執行緒的，WaitSet則是Java中呼叫wait方法進入阻塞的執行緒，owner指向當前獲取鎖的執行緒，而Read Thread則表示從cxq和EntryList中挑選出來去搶鎖的執行緒，但由於是非公平鎖，所以不一定能搶到鎖。 在膨脹為重量鎖的時候若沒有獲取到鎖，不是立馬就阻塞未獲取到鎖的執行緒，因其是**非公平鎖**，首先會去嘗試加鎖，不管前面是否有執行緒等待（如果是公平鎖的話就會判斷是否有執行緒等待，有的話則直接入隊睡眠），如果加鎖失敗，synchronized還會採用自旋的方式去獲取鎖，JDK1.6之前是預設自旋10次後睡眠，而優化之後引入了**適應性自旋**，即JVM會根據各種情況動態改變自旋次數： > - 如果平均負載小於CPU則一直自旋 > - 如果有超過(CPU/2)個執行緒正在自旋，則後來執行緒直接阻塞 > - 如果正在自旋的執行緒發現Owner發生了變化則延遲自旋時間（自旋計數）或進入阻塞 > - 如果CPU處於節電模式則停止自旋 > - 自旋時間的最壞情況是CPU的儲存延遲（CPU A儲存了一個數據，到CPU B得知這個資料直接的時間差） > - 自旋時會適當放棄執行緒優先順序之間的差異 你可能會比較好奇為什麼不一直採用自旋，因為自旋是會消耗CPU的，適合併發數不多或自旋次數少的情形，否則不如直接呼叫系統函式進入睡眠狀態。 所以當自旋沒有獲取到鎖，則會將當前執行緒新增到cxq佇列的隊首（注意在入隊後還會搶一次鎖，這就是非公平鎖的特點，儘可能的避免呼叫系統函式進入核心態阻塞）並呼叫park函式睡眠。 park函式是基於**pthread_mutex_lock**函式實現的，而Java中的LockSupport.park則是基於**pthread_cond_timedwait**函式，這兩個都是**系統函式**，更底層則是通過**futex**實現（注意此處都是基於Linux系統討論，其它不同的作業系統有不同的實現方式），這裡就不展開討論了。 需要注意執行緒一旦進入佇列後，執行的順序就是固定了，因為在當前持有鎖的執行緒釋放鎖後，會從佇列中喚醒**最後入隊**的執行緒，即**一朝排隊，永遠排隊**，所以**公平鎖**和**非公平鎖**的區別就體現在入隊前是否搶鎖（排除有新的執行緒來搶鎖的情況）。 所謂喚醒最後入隊的執行緒，其實就類似於棧，**先睡眠的執行緒後喚醒**，這點和ReentratLock是相反的，下面給出證明： ```java public class Demo2 { private static Demo2 lock = new Demo2(); public static void main(String[] args) throws InterruptedException { Thread[] threads = new Thread[10]; for (int i = 0; i < 10; i++) { threads[i] = new Thread(() -> { synchronized (lock) { log.info(Thread.currentThread().getName()); } }); } synchronized (lock) { for (Thread thread : threads) { thread.start(); // 睡眠一下保證執行緒的啟動順序 Thread.sleep(100); } } } } ``` 上面程式建立了10個執行緒，然後主執行緒拿到鎖後依次啟動10個執行緒，這10個執行緒內又會分別去獲取鎖，因為被主執行緒佔有，就會膨脹為重量鎖進入阻塞，最終列印結果如下： ``` 16:25:49.877 [Thread-9] INFO cn.dark.mydemo.sync.Demo2 - Thread-9 16:25:49.879 [Thread-8] INFO cn.dark.mydemo.sync.Demo2 - Thread-8 16:25:49.879 [Thread-7] INFO cn.dark.mydemo.sync.Demo2 - Thread-7 16:25:49.879 [Thread-6] INFO cn.dark.mydemo.sync.Demo2 - Thread-6 16:25:49.879 [Thread-5] INFO cn.dark.mydemo.sync.Demo2 - Thread-5 16:25:49.879 [Thread-4] INFO cn.dark.mydemo.sync.Demo2 - Thread-4 16:25:49.879 [Thread-3] INFO cn.dark.mydemo.sync.Demo2 - Thread-3 16:25:49.879 [Thread-2] INFO cn.dark.mydemo.sync.Demo2 - Thread-2 16:25:49.879 [Thread-1] INFO cn.dark.mydemo.sync.Demo2 - Thread-1 16:25:49.879 [Thread-0] INFO cn.dark.mydemo.sync.Demo2 - Thread-0 ``` 可以看到10個執行緒並不是按照啟動順序執行的，而是以相反的順序被喚醒並執行。 以上就是Synchronized的膨脹過程以及底層的一些實現原理，最後我畫了一張synchronized鎖膨脹過程的圖幫助理解，有不對的地方歡迎指出：  # 總結 通過兩篇文章分析了synchronized的實現原理，可以看到要實現一把高效能的鎖是相當複雜的，這也是為什麼JDK1.6才對synchronized進行了優化（大概也是迫於ReentratLock的壓力吧），優化過後效能基本上和ReentrantLock差不多，只不過後者使用上更加靈活，支援更多的高階特性，但思想上其實都是一樣的（應該都是借鑑了futex的實現原理）。 深刻理解synchronized的膨脹過程，不僅僅用於應付面試，而是能夠更好的使用它進行併發程式設計，比如何時加鎖，何時使用無鎖的自旋鎖。另外在進行業務開發遇到類似場景時也可以借鑑其思想。 本篇文章參考了以下文章，最後在此表示感謝，讓我少走了很多彎路，也瞭解了很多底層知識。 - [linux核心級同步機制--futex](https://github.com/farmerjohngit/myblog/issues/8) - [死磕Synchronized底層實現--偏向鎖](https://github.com/farmerjohngit/myblog/issues/13) - [死磕Synchronized底層實現--輕量級鎖](https://github.com/farmerjohngit/myblog/issues/14) - [死磕Synchronized底層實現--重量級鎖](https://github.com/farmerjohngit/myblog/issues/15) - [synchronized實現原理及其優化-（自旋鎖，偏向鎖，輕量鎖，重量鎖）](https://www.cnblogs.com/ljl150/p/125141