synchronized 鎖漫漫升級路

在圖文詳解Java對象內(nèi)存布局這篇文章中，在研究對象頭時我們了解了synchronized鎖升級的過程，由于篇幅有限，對鎖升級的過程介紹的比較簡略，本文在上一篇的基礎(chǔ)上，來詳細(xì)研究一下鎖升級的過程以及各個狀態(tài)下鎖的原理。本文結(jié)構(gòu)如下：

• 1 無鎖

• 2 偏向鎖

• 3 輕量級鎖

• 4 重量級鎖

• 總結(jié)

1 無鎖

在上一篇文章中，我們提到過 jvm會有4秒的偏向鎖開啟的延遲時間，在這個偏向延遲內(nèi)對象處于為無鎖態(tài)。如果關(guān)閉偏向鎖啟動延遲、或是經(jīng)過4秒且沒有線程競爭對象的鎖，那么對象會進(jìn)入無鎖可偏向狀態(tài)。

準(zhǔn)確來說，無鎖可偏向狀態(tài)應(yīng)該叫做匿名偏向(Anonymously biased)狀態(tài)，因為這時對象的mark word中后三位已經(jīng)是101，但是threadId指針部分仍然全部為0，它還沒有向任何線程偏向。綜上所述，對象在剛被創(chuàng)建時，根據(jù)jvm的配置對象可能會處于 無鎖 或 匿名偏向 兩個狀態(tài)。

此外，如果在jvm的參數(shù)中關(guān)閉偏向鎖，那么直到有線程獲取這個鎖對象之前，會一直處于無鎖不可偏向狀態(tài)。修改jvm啟動參數(shù)：

-XX:-UseBiasedLocking

延遲5s后打印對象內(nèi)存布局：

public?static?void?main(String[]?args)?throws?InterruptedException?{
????User?user=new?User();
????TimeUnit.SECONDS.sleep(5);
????System.out.println(ClassLayout.parseInstance(user).toPrintable());
}

可以看到，即使經(jīng)過一定的啟動延時，對象一直處于001無鎖不可偏向狀態(tài)。大家可能會有疑問，在無鎖狀態(tài)下，為什么要存在一個不可偏向狀態(tài)呢？通過查閱資料得到的解釋是：

JVM內(nèi)部的代碼有很多地方也用到了synchronized，明確在這些地方存在線程的競爭，如果還需要從偏向狀態(tài)再逐步升級，會帶來額外的性能損耗，所以JVM設(shè)置了一個偏向鎖的啟動延遲，來降低性能損耗

也就是說，在無鎖不可偏向狀態(tài)下，如果有線程試圖獲取鎖，那么將跳過升級偏向鎖的過程，直接使用輕量級鎖。使用代碼進(jìn)行驗證：

//-XX:-UseBiasedLocking
public?static?void?main(String[]?args)?throws?InterruptedException?{
????User?user=new?User();
????synchronized?(user){
????????System.out.println(ClassLayout.parseInstance(user).toPrintable());
????}
}

查看結(jié)果可以看到，在關(guān)閉偏向鎖情況下使用synchronized，鎖會直接升級為輕量級鎖（00狀態(tài)）:

在目前的基礎(chǔ)上，可以用流程圖概括上面的過程：

額外注意一點就是匿名偏向狀態(tài)下，如果調(diào)用系統(tǒng)的hashCode()方法，會使對象回到無鎖態(tài)，并在markword中寫入hashCode。并且在這個狀態(tài)下，如果有線程嘗試獲取鎖，會直接從無鎖升級到輕量級鎖，不會再升級為偏向鎖。

2 偏向鎖

2.1 偏向鎖原理

匿名偏向狀態(tài)是偏向鎖的初始狀態(tài)，在這個狀態(tài)下第一個試圖獲取該對象的鎖的線程，會使用CAS操作（匯編命令CMPXCHG）嘗試將自己的threadID寫入對象頭的mark word中，使匿名偏向狀態(tài)升級為已偏向（Biased）的偏向鎖狀態(tài)。在已偏向狀態(tài)下，線程指針threadID非空，且偏向鎖的時間戳epoch為有效值。

如果之后有線程再次嘗試獲取鎖時，需要檢查mark word中存儲的threadID是否與自己相同即可，如果相同那么表示當(dāng)前線程已經(jīng)獲得了對象的鎖，不需要再使用CAS操作來進(jìn)行加鎖。

如果mark word中存儲的threadID與當(dāng)前線程不同，那么將執(zhí)行CAS操作，試圖將當(dāng)前線程的ID替換mark word中的threadID。只有當(dāng)對象處于下面兩種狀態(tài)中時，才可以執(zhí)行成功：

• 對象處于匿名偏向狀態(tài)
• 對象處于可重偏向（Rebiasable）狀態(tài)，新線程可使用CAS將threadID指向自己

如果對象不處于上面兩個狀態(tài)，說明鎖存在線程競爭，在CAS替換失敗后會執(zhí)行偏向鎖撤銷操作。偏向鎖的撤銷需要等待全局安全點Safe Point（安全點是 jvm為了保證在垃圾回收的過程中引用關(guān)系不會發(fā)生變化設(shè)置的安全狀態(tài)，在這個狀態(tài)上會暫停所有線程工作），在這個安全點會掛起獲得偏向鎖的線程。

在暫停線程后，會通過遍歷當(dāng)前jvm的所有線程的方式，檢查持有偏向鎖的線程狀態(tài)是否存活：

• 如果線程還存活，且線程正在執(zhí)行同步代碼塊中的代碼，則升級為輕量級鎖

• 如果持有偏向鎖的線程未存活，或者持有偏向鎖的線程未在執(zhí)行同步代碼塊中的代碼，則進(jìn)行校驗是否允許重偏向：

• 不允許重偏向，則撤銷偏向鎖，將mark word升級為輕量級鎖，進(jìn)行CAS競爭鎖

• 允許重偏向，設(shè)置為匿名偏向鎖狀態(tài)，CAS將偏向鎖重新指向新線程

完成上面的操作后，喚醒暫停的線程，從安全點繼續(xù)執(zhí)行代碼。可以使用流程圖總結(jié)上面的過程：

2.2 偏向鎖升級

在上面的過程中，我們已經(jīng)知道了匿名偏向狀態(tài)可以變?yōu)闊o鎖態(tài)或升級為偏向鎖，接下來看一下偏向鎖的其他狀態(tài)的改變

• 偏向鎖升級為輕量級鎖

public?static?void?main(String[]?args)?throws?InterruptedException?{
????User?user=new?User();
????synchronized?(user){
????????System.out.println(ClassLayout.parseInstance(user).toPrintable());
????}
????Thread?thread?=?new?Thread(()?->?{
????????synchronized?(user)?{
????????????System.out.println("--THREAD--:"+ClassLayout.parseInstance(user).toPrintable());
????????}
????});
????thread.start();
????thread.join();
????System.out.println("--END--:"+ClassLayout.parseInstance(user).toPrintable());
}

查看內(nèi)存布局，偏向鎖升級為輕量級鎖，在執(zhí)行完成同步代碼后釋放鎖，變?yōu)闊o鎖不可偏向狀態(tài)：

• 偏向鎖升級為重量級鎖

public?static?void?main(String[]?args)?throws?InterruptedException?{
????User?user=new?User();
????Thread?thread?=?new?Thread(()?->?{
????????synchronized?(user)?{
????????????System.out.println("--THREAD1--:"?+?ClassLayout.parseInstance(user).toPrintable());
????????????try?{
????????????????user.wait(2000);
????????????}?catch?(InterruptedException?e)?{
????????????????e.printStackTrace();
????????????}
????????????System.out.println("--THREAD?END--:"?+?ClassLayout.parseInstance(user).toPrintable());
????????}
????});
????thread.start();
????thread.join();
????TimeUnit.SECONDS.sleep(3);
????System.out.println(ClassLayout.parseInstance(user).toPrintable());
}

查看內(nèi)存布局，可以看到在調(diào)用了對象的wait()方法后，直接從偏向鎖升級成了重量級鎖，并在鎖釋放后變?yōu)闊o鎖態(tài)：

這里是因為wait()方法調(diào)用過程中依賴于重量級鎖中與對象關(guān)聯(lián)的monitor，在調(diào)用wait()方法后monitor會把線程變?yōu)?code style="font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">WAITING狀態(tài)，所以才會強(qiáng)制升級為重量級鎖。除此之外，調(diào)用hashCode方法時也會使偏向鎖直接升級為重量級鎖。

在上面分析的基礎(chǔ)上，再加上我們上一篇中講到的輕量級鎖升級到重量級鎖的知識，就可以對上面的流程圖進(jìn)行完善了：

2.3 批量重偏向

在未禁用偏向鎖的情況下，當(dāng)一個線程建立了大量對象，并且對它們執(zhí)行完同步操作解鎖后，所有對象處于偏向鎖狀態(tài)，此時若再來另一個線程也嘗試獲取這些對象的鎖，就會導(dǎo)偏向鎖的批量重偏向（Bulk Rebias）。當(dāng)觸發(fā)批量重偏向后，第一個線程結(jié)束同步操作后的鎖對象當(dāng)再被同步訪問時會被重置為可重偏向狀態(tài)，以便允許快速重偏向，這樣能夠減少撤銷偏向鎖再升級為輕量級鎖的性能消耗。

首先看一下和偏向鎖有關(guān)的參數(shù)，修改jvm啟動參數(shù)，使用下面的命令可以在項目啟動時打印jvm的默認(rèn)參數(shù)值：

-XX:+PrintFlagsFinal

需要關(guān)注的屬性有下面3個：

• BiasedLockingBulkRebiasThreshold：偏向鎖批量重偏向閾值，默認(rèn)為20次
• BiasedLockingBulkRevokeThreshold：偏向鎖批量撤銷閾值，默認(rèn)為40次
• BiasedLockingDecayTime：重置計數(shù)的延遲時間，默認(rèn)值為25000毫秒（即25秒）

批量重偏向是以class而不是對象為單位的，每個class會維護(hù)一個偏向鎖的撤銷計數(shù)器，每當(dāng)該class的對象發(fā)生偏向鎖的撤銷時，該計數(shù)器會加一，當(dāng)這個值達(dá)到默認(rèn)閾值20時，jvm就會認(rèn)為這個鎖對象不再適合原線程，因此進(jìn)行批量重偏向。而距離上次批量重偏向的25秒內(nèi)，如果撤銷計數(shù)達(dá)到40，就會發(fā)生批量撤銷，如果超過25秒，那么就會重置在[20, 40)內(nèi)的計數(shù)。

上面這段理論是不是聽上去有些難理解，沒關(guān)系，我們先用代碼驗證批量重偏向的過程：

private?static?Thread?t1,t2;
public?static?void?main(String[]?args)?throws?InterruptedException?{??????
????TimeUnit.SECONDS.sleep(5);
????List