前言

今天的文章從下面這張圖片開始，這張圖片Java開發(fā)們應該很熟悉了

我們都知道無鎖狀態(tài)是對象頭是有位置存儲hashcode的，而變?yōu)槠蜴i狀態(tài)是沒有位置存儲hashcode的，今天我們來通過實現(xiàn)驗證這個問題：當鎖狀態(tài)為偏向鎖的時候，hashcode存到哪里去了？

先說結論：

• jdk8偏向鎖是默認開啟，但是是有延時的
  可通過參數(shù)： -XX:BiasedLockingStartupDelay=0關閉延時。
• hashcode是懶加載，在調(diào)用hashCode方法后才會保存在對象頭中。
• 當對象頭中沒有hashcode時，對象頭鎖的狀態(tài)是 可偏向（ biasable，101，且無線程id）。
• 如果在同步代碼塊之前調(diào)用hashCode方法，則對象頭中會有hashcode，且鎖狀態(tài)是 不可偏向（0 01），這時候再執(zhí)行同步代碼塊，鎖直接是 輕量級鎖（thin lock，00）。

如果是在同步代碼塊中執(zhí)行hashcode，則鎖是從 偏向鎖 直接膨脹為 重量級鎖。

1、hashcode是啥時候存進對象頭中？

根據(jù)下圖我們可知，hashcode并不是對象實例化后就創(chuàng)建，而是在調(diào)用默認的hasCode方法時才會放進對象頭。

第一次打印的對象頭中我們發(fā)現(xiàn)對象頭中mark word值為16進制的5，轉為2進制就是101，且后面的狀態(tài)顯示為biasable，也就是可偏向，注意區(qū)分可偏向和已偏向：可偏向表示還么有synchronized鎖，已偏向表示有線程訪問鎖。

第二次打印對象頭中已經(jīng)存在hashcode，value為0x00000039a054a501，轉換為2進制為：11100110100000010101001010010100000001，最后三位也就是0 01，這就表示不可偏向，也就說當出現(xiàn)synchronized鎖不會進行偏向，真是如此嗎？我們驗證一下！

2、存在hashcode后，出現(xiàn)synchronized會是什么鎖？

根據(jù)下圖我們可以清晰的看到，當已存在hashcode再執(zhí)行同步代碼，則會直接進入輕量級鎖，原因還是上面的結論，有hashcode后將鎖設置為 不可偏向，那肯定就直接上輕量級鎖咯。

3、如果鎖狀態(tài)是 已偏向，再計算hashcode會怎樣？

前面兩種情況鎖狀態(tài)都是 可偏向 狀態(tài)，如果此時鎖狀態(tài)是 已經(jīng)進入偏向狀態(tài)呢？是會進行鎖升級嘛？

根據(jù)下圖我們可以看到，當hashCode方法處于synchronized代碼塊中時，鎖直接升級為重量級鎖。

至于為什么直接升級為重量級鎖而不是輕量級鎖，這個原因不得而知。

豬哥猜想可能無線程競爭狀態(tài)下，偏向鎖升級為重量級鎖消耗的資源比輕量級鎖消耗的資源少。

同時歡迎知道原因的同學能夠留言告知，也歡迎大家說出自己的猜想？沒準以后會根據(jù)你的方案優(yōu)化呢！

4、總結

• jdk8偏向鎖是默認開啟，但是是有延時的，可通過參數(shù)： -XX:BiasedLockingStartupDelay=0關閉延時。
• hashcode是懶加載，在調(diào)用hashCode方法后才會保存在對象頭中。
• 當對象頭中沒有hashcode時，對象頭鎖的狀態(tài)是 可偏向（ biasable，101，且無線程id）。
• 如果在同步代碼塊之前調(diào)用hashCode方法，則對象頭中會有hashcode，且鎖狀態(tài)是 不可偏向（0 01），這時候再執(zhí)行同步代碼塊，鎖直接是 輕量級鎖（thin lock，00）。
• 如果是在同步代碼塊中執(zhí)行hashcode，則鎖是從 偏向鎖 直接膨脹為 重量級鎖。

以上就是Java面試synchronized偏向鎖后hashcode存址的詳細內(nèi)容，更多關于java 偏向鎖hashcode存址的資料請關注腳本之家其它相關文章！

最新評論