在HotSpot虛擬機(jī)里，對象在堆內(nèi)存中的存儲布局可以劃分為三個(gè)部分：

對象頭（Header）

實(shí)例數(shù)據(jù)（Instance Data）

對齊填充（Padding）。

對象頭

HotSpot虛擬機(jī)(后面沒有說明的話默認(rèn)是這個(gè)虛擬機(jī))對象頭包括三部分:

1. Mark Word
2. 指向類的指針
3. 數(shù)組長度（只有數(shù)組對象才有）

對象頭之Mark Word

Mark Word記錄了對象和鎖有關(guān)的信息，當(dāng)這個(gè)對象被synchronized關(guān)鍵字當(dāng)成同步鎖時(shí)，圍繞這個(gè)鎖的一系列操作都和Mark Word有關(guān)。

Mark Word在32位JVM中的長度是32bit，在64位JVM中長度是64bit。

Mark Word在不同的鎖狀態(tài)下存儲的內(nèi)容不同，在32位JVM中是這么存的:

一共32位,兩位用來記錄鎖的信息,1位用來記錄是否是偏向鎖,如果偏向鎖是1的話,那么會分配23位來記錄偏向的線程id,當(dāng)計(jì)算過Hash后,意味著會分配25bit來記錄HashCode,那么久沒有空間用來記錄偏向鎖的線程ID了,所以計(jì)算過HashCode后就沒法再進(jìn)入偏向鎖。如果進(jìn)入輕量級鎖或者重量級鎖,意味著會用30bit指向指針,那么此時(shí)對象頭中就只有兩種信息,鎖標(biāo)志、指向鎖的指針。

其中無鎖和偏向鎖的鎖標(biāo)志位都是01，只是在前面的1bit區(qū)分了這是無鎖狀態(tài)還是偏向鎖狀態(tài)。

JDK1.6以后的版本在處理同步鎖時(shí)存在鎖升級的概念，JVM對于同步鎖的處理是從偏向鎖開始的，隨著競爭越來越激烈，處理方式從偏向鎖升級到輕量級鎖，最終升級到重量級鎖。

結(jié)合Mark Word分析鎖升級的流程：

1，當(dāng)沒有被當(dāng)成鎖時(shí)，這就是一個(gè)普通的對象，Mark Word記錄對象的HashCode，鎖標(biāo)志位是01，是否偏向鎖那一位是0(0則false , 1 則true)。

2，當(dāng)對象被當(dāng)做同步鎖并有一個(gè)線程A搶到了鎖時(shí)，鎖標(biāo)志位還是01，但是否偏向鎖那一位改成1，前23bit記錄搶到鎖的線程id，表示進(jìn)入偏向鎖狀態(tài)。

3，當(dāng)線程A再次試圖來獲得鎖時(shí)，JVM發(fā)現(xiàn)同步鎖對象的標(biāo)志位是01，是否偏向鎖是1，也就是偏向狀態(tài)，Mark Word中記錄的線程id就是線程A自己的id，表示線程A已經(jīng)獲得了這個(gè)偏向鎖，可以執(zhí)行同步鎖的代碼。

4，當(dāng)線程B試圖獲得這個(gè)鎖時(shí)，JVM發(fā)現(xiàn)同步鎖處于偏向狀態(tài)，但是Mark Word中的線程id記錄的不是B，那么線程B會先用CAS操作試圖獲得鎖，這里的獲得鎖操作是有可能成功的，因?yàn)榫€程A一般不會自動(dòng)釋放偏向鎖。如果搶鎖成功，就把Mark Word里的線程id改為線程B的id，代表線程B獲得了這個(gè)偏向鎖，可以執(zhí)行同步鎖代碼。如果搶鎖失敗，則繼續(xù)執(zhí)行步驟5。

5，偏向鎖狀態(tài)搶鎖失敗，代表當(dāng)前鎖有一定的競爭，偏向鎖將升級為輕量級鎖。JVM會在當(dāng)前線程的線程棧中開辟一塊單獨(dú)的空間，里面保存指向?qū)ο箧iMark Word的副本，同時(shí)在對象鎖Mark Word中保存指向這片空間的指針。上述兩個(gè)保存操作都是CAS操作，如果保存成功，代表線程搶到了同步鎖，就把Mark Word中的鎖標(biāo)志位改成00，可以執(zhí)行同步鎖代碼。如果保存失敗，表示搶鎖失敗，競爭太激烈，繼續(xù)執(zhí)行步驟6。

6，輕量級鎖搶鎖失敗，JVM會使用自旋鎖，自旋鎖不是一個(gè)鎖狀態(tài)，只是代表不斷的重試，嘗試搶鎖。從JDK1.7開始，自旋鎖默認(rèn)啟用，自旋次數(shù)由JVM決定。如果搶鎖成功則執(zhí)行同步鎖代碼，如果失敗則繼續(xù)執(zhí)行步驟7。

7，自旋鎖重試之后如果搶鎖依然失敗，同步鎖會升級至重量級鎖，鎖標(biāo)志位改為10。在這個(gè)狀態(tài)下，未搶到鎖的線程都會被阻塞。

對象頭之指向類的指針

該指針在32位JVM中的長度是32bit，在64位JVM中長度是64bit。

Java對象的類數(shù)據(jù)保存在方法區(qū)。 并不是所有的虛擬機(jī)實(shí)現(xiàn)都必須在對象數(shù)據(jù)上保留類型指針，換句話說，查找對象的元數(shù)據(jù)信息并不一定要經(jīng)過對象本身。

對象頭之?dāng)?shù)組長度

如果對象是一個(gè)Java數(shù)組，那在對象頭中還必須有一塊用于記錄數(shù)組長度的數(shù)據(jù)，因?yàn)樘摂M機(jī)可以通過普通Java對象的元數(shù)據(jù)信息確定Java對象的大小，但是如果數(shù)組的長度是不確定的，將無法通過元數(shù)據(jù)中的信息推斷出數(shù)組的大小。

只有數(shù)組對象保存了這部分?jǐn)?shù)據(jù), 該數(shù)據(jù)在32位和64位JVM中長度都是32bit。

實(shí)例數(shù)據(jù)

實(shí)例數(shù)據(jù)部分是對象真正存儲的有效信息，即我們在程序代碼里面所定義的各種類型的字段內(nèi)容，無論是從父類繼承下來的，還是在子類中定義的字段都必須記錄起來。這部分的存儲順序會受到虛擬機(jī)分配策略參數(shù)（-XX：FieldsAllocationStyle參數(shù)）和字段在Java源碼中定義順序的影響。HotSpot虛擬機(jī)默認(rèn)的分配順序?yàn)?code>longs/doubles、ints、shorts/chars、bytes/booleans、oops（OrdinaryObject Pointers，OOPs），從以上默認(rèn)的分配策略中可以看到，相同寬度的字段總是被分配到一起存放，在滿足這個(gè)前提條件的情況下，在父類中定義的變量會出現(xiàn)在子類之前。如果HotSpot虛擬機(jī)的+XX：CompactFields參數(shù)值為true（默認(rèn)就為true），那子類之中較窄的變量也允許插入父類變量的空隙之中，以節(jié)省出一點(diǎn)點(diǎn)空間。

對齊填充

這并不是必然存在的，也沒有特別的含義，它僅僅起著占位符的作用。由于HotSpot虛擬機(jī)的自動(dòng)內(nèi)存管理系統(tǒng)要求對象起始地址必須是8字節(jié)的整數(shù)倍，換句話說就是任何對象的大小都必須是8字節(jié)的整數(shù)倍。對象頭部分已經(jīng)被精心設(shè)計(jì)成正好是8字節(jié)的倍數(shù)（1倍或者2倍），因此，如果對象實(shí)例數(shù)據(jù)部分沒有對齊的話，就需要通過對齊填充來補(bǔ)全。

到此這篇關(guān)于JAVA對象分析之偏向鎖、輕量級鎖、重量級鎖升級過程的文章就介紹到這了,更多相關(guān)偏向鎖、輕量級鎖、重量級鎖升級過程內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！