前言

上一篇分析了優化后的synchronized在不同場景下物件頭中的表現形式，還記得那個結論嗎？當一個執行緒第一次獲取鎖后再去拿鎖就是偏向鎖，如果有別的執行緒和當前執行緒交替執行就膨脹為輕量級鎖，如果發生競爭就會膨脹為重量級鎖，這句話看起來很簡單，但實際上synhronized的膨脹程序是非常復雜的，有許多場景和細節需要考慮，本篇就對其進行詳細分析，

正文

先來看一個案例代碼：

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<A> 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位展示）

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執行緒的列印結果）：

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，觀察結果：

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關于這一點的原始碼：

  // 當前時間
  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是相反的，下面給出證明：

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
死磕Synchronized底層實作–偏向鎖
死磕Synchronized底層實作–輕量級鎖
死磕Synchronized底層實作–重量級鎖
synchronized實作原理及其優化-（自旋鎖，偏向鎖，輕量鎖，重量鎖）

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

標籤：其他

上一篇：函式傳參求助

下一篇：影響UWB定位精度的原因分析

synchronized的實作原理——鎖膨脹程序

文章目錄

前言

正文

偏向鎖

輕量鎖

批量重偏向

批量撤銷

重量鎖

總結