@
前言
上一篇分析了優化後的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的膨脹過程，不僅僅用於應付面試，而是能夠更好的使用它進行併發程式設計，比如何時加鎖，何時使用無鎖的自旋鎖。另外在進行業務開發遇到類似場景時也可以借鑑其思想。
本篇文章參考了以下文章，最後在此表示感謝，讓我少走了很多彎路，也瞭解了很多底層知識。