從理論到實踐，刨根問底探索Java物件記憶體布局
所謂物件的記憶體布局，就是物件在分配到記憶體中后的存盤格式，
物件在記憶體中的布局一共包含三部分：
- 物件頭（Header）
- 實體資料（Instance Data）
- 對齊填充（Padding）
第一部分：物件頭
首先來看一下物件頭的結構
Java物件頭分為兩部分：
- Mark Word：物件自身運行時資料，
- Klass Pointer：型別指標，即物件指向它的類元資料的指標，
1、Mark Word
為啥叫Mark Word呢？我理解因為這部分是用來標記物件運行時的資料和狀態，比如物件的HashCode、GC分代年齡、鎖狀態標志、執行緒持有的鎖、偏向執行緒ID等，而Word呢，是因為這段資訊是用一個Word（字）長度來保存的，在32位系統中，一個字是32bit，也就是4位元組，64位系統中，一個字是64bit，也就是8位元組，
對于這部分的描述，從markOop.hpp原始碼的注釋中即可得知，
下面就以32位的虛擬機為例，來探尋一下物件頭的Mark Word部分是什么樣的資料結構，
先劃重點，鎖狀態很重要
這里要注意兩點：
- 物件頭的資料格式和物件的鎖狀態緊密相關，在不同的鎖狀態下，物件頭的結構都不一樣，其目的是為了盡量在極小的空間記憶體儲盡量多的資訊，
- 鎖狀態的標志位是固定的，無論是32位還是64位的虛擬機，物件頭中最后兩位就是鎖的狀態標志，
既然鎖的狀態很重要，那么就先看一下下鎖標志對應的狀態含義：
| lock | 狀態 |
|---|---|
| 01 | 無鎖 |
| 00 | 輕量級鎖（locked） |
| 10 | 重量級鎖（monitor，inflated lock） |
| 11 | GC標記（marked） |
01-無鎖狀態下的Mark Word結構
無鎖狀態下，涉及到兩種情況：
- 稀松平常的無鎖狀態
- 偏向鎖
是否存在偏向鎖，我們也是用1位長的標識來判斷，
當不存在偏向鎖時，1-25位是物件的HashCode，之后的4位是物件GC的分代年齡，之后的1位是偏向鎖的標志，此時該標志為0，
當存在偏向鎖時，1-23為是持有偏向鎖的執行緒的ID，之后的2位是偏向時間戳，然后4位依舊是物件GC的分代年齡，再之后的1位是偏向鎖的標志，此時該標志為1，
00-輕量級鎖狀態下的Mark Word結構
輕量級鎖狀態時，物件頭的前30位保存指向持有鎖的執行緒的堆疊幀中鎖記錄的指標，
此時，獲取了該物件偏向鎖的執行緒，會在執行緒的堆疊幀上建立鎖記錄的空間，并通過CAS的方式將物件頭的資訊復制到鎖記錄的位置，并將物件頭替換成指向鎖記錄的指標，
10-重量級鎖狀態下的Mark Word結構
當有兩個及以上的執行緒競爭同一個鎖，則輕量級鎖就會升級成重量級鎖，此時物件頭的前30位保存的是指向重量級鎖Monitor的指標，
關于Monitor，這里可以做個簡單的理解：Java的重量級鎖，是通過一個Monitor物件來實作的，JVM通過Monitor物件中的_owner、_EntryList來維護是哪個執行緒持有這個物件的鎖，以及后續的阻塞執行緒，原始碼在objectWaiter.hpp中可以深入了解，
11-GC標記
當最后兩位為11時，代表被GC標記了，則物件頭前面的30位資訊為空，
Mark Word 小結
在這里根據上面的描述，畫個圖來展示一下Mark Word這部分資料在32位系統和62位系統里的布局，更直觀清晰一些，
2、Klass Pointer（型別指標）
緊跟著Mark Word，是物件頭的另一部分——型別指標，型別指標也是用一個字的長度（32位系統是4byte，64位系統是8byte）來保存的，這個指標會指向該物件對應的類元資料，說人話就是，JVM通過這個指標知道這個物件是哪個類的實體，
3、陣列長度
如果這是一個普通的Java物件，則物件頭中只有Mark Word和Klass Pointer兩部分，當它是一個陣列物件時，物件頭中還需要一部分空間來保存陣列的長度，有了陣列長度，JVM才能夠知道一個陣列物件的大小，陣列長度這部分也是用一個字的長度（32位系統是4byte，64位系統是8byte）來保存，
如果64位的JVM開啟了+UseCompressedOops選項，則型別指標和陣列長度這兩個區域都會被壓縮成32位，
第二部分：實體資料
這部分就是物件真正存盤的有效資訊，也就是類里定義的各種型別欄位的內容，
第三部分：對齊填充
這部分沒有實際的含義，僅僅是起到占位符的作用，因為JVM要求物件起始地址必須是8位元組的整數倍，也就是一個物件的大小必須是8位元組的整數倍，所以如果一個物件的實體資料不滿足8位元組的整數倍，則需要做一個對齊填充的操作，保證物件的大小是8位元組的整數倍，
實踐一下
接下來我們來跑幾個demo看看真實的物件頭布局，借助JOL（Java Object Layout），我們可以分析JVM中物件的布局，
環境：64位系統，JDK8，
1、引入JOL依賴
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
2、一個簡單的類
public class OneObject {
private int id;
private String name;
private double score;
}
3、列印物件記憶體布局
這里選擇了五種情況：
- 剛剛new出來的新鮮物件
- 經歷過gc后的物件
- 加鎖時的物件（偏向鎖）
- 多執行緒競爭鎖時的物件（重量級鎖）
- 算一下物件的hashCode
代碼如下：
@Test
public void showObjectData() throws InterruptedException {
OneObject object = new OneObject();
log.info("初始化后的物件布局：{}", ClassLayout.parseInstance(object).toPrintable());
System.gc();
log.info("gc一次之后的物件布局：{}", ClassLayout.parseInstance(object).toPrintable());
synchronized (object) {
log.info("加鎖時的物件布局：{}", ClassLayout.parseInstance(object).toPrintable());
}
for (int i = 0; i < 2; i++) {
Thread thread = new Thread(()->{
synchronized (object) {
log.info("競爭鎖時的物件布局：{}", ClassLayout.parseInstance(object).toPrintable());
}
});
thread.start();
}
Thread.sleep(500);
object.hashCode();
log.info("計算完hashCode的物件布局：{}", ClassLayout.parseInstance(object).toPrintable());
}
4、輸出結果
執行以上的代碼，輸出結果如下：
00:06:03.877 [main] INFO com.esparks.pandora.learning.vm.LearnObjectData - 初始化后的物件布局：com.esparks.pandora.learning.vm.OneObject object internals:
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) 38 a1 08 00 (00111000 10100001 00001000 00000000) (565560)
12 4 int OneObject.id 0
16 8 double OneObject.score 0.0
24 4 java.lang.String OneObject.name null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
00:06:03.890 [main] INFO com.esparks.pandora.learning.vm.LearnObjectData - gc一次之后的物件布局：com.esparks.pandora.learning.vm.OneObject object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 09 00 00 00 (00001001 00000000 00000000 00000000) (9)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 38 a1 08 00 (00111000 10100001 00001000 00000000) (565560)
12 4 int OneObject.id 0
16 8 double OneObject.score 0.0
24 4 java.lang.String OneObject.name null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
00:06:03.891 [main] INFO com.esparks.pandora.learning.vm.LearnObjectData - 加鎖時的物件布局：com.esparks.pandora.learning.vm.OneObject object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 90 99 0b 6d (10010000 10011001 00001011 01101101) (1829476752)
4 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
8 4 (object header) 38 a1 08 00 (00111000 10100001 00001000 00000000) (565560)
12 4 int OneObject.id 0
16 8 double OneObject.score 0.0
24 4 java.lang.String OneObject.name null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
00:06:03.892 [Thread-1] INFO com.esparks.pandora.learning.vm.LearnObjectData - 競爭鎖時的物件布局：com.esparks.pandora.learning.vm.OneObject object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 62 d9 00 20 (01100010 11011001 00000000 00100000) (536926562)
4 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
8 4 (object header) 38 a1 08 00 (00111000 10100001 00001000 00000000) (565560)
12 4 int OneObject.id 0
16 8 double OneObject.score 0.0
24 4 java.lang.String OneObject.name null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
00:06:03.893 [Thread-2] INFO com.esparks.pandora.learning.vm.LearnObjectData - 競爭鎖時的物件布局：com.esparks.pandora.learning.vm.OneObject object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 62 d9 00 20 (01100010 11011001 00000000 00100000) (536926562)
4 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
8 4 (object header) 38 a1 08 00 (00111000 10100001 00001000 00000000) (565560)
12 4 int OneObject.id 0
16 8 double OneObject.score 0.0
24 4 java.lang.String OneObject.name null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
00:06:04.398 [main] INFO com.esparks.pandora.learning.vm.LearnObjectData - 計算完hashCode的物件布局：com.esparks.pandora.learning.vm.OneObject object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 09 63 c1 aa (00001001 01100011 11000001 10101010) (-1430166775)
4 4 (object header) 56 00 00 00 (01010110 00000000 00000000 00000000) (86)
8 4 (object header) 38 a1 08 00 (00111000 10100001 00001000 00000000) (565560)
12 4 int OneObject.id 0
16 8 double OneObject.score 0.0
24 4 java.lang.String OneObject.name null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
Process finished with exit code 0
物件布局分析
這里我們先以第一種情況的物件布局來簡單說明輸出的格式，直接在圖上標明啦，
這里要插一句，JOL在輸出物件頭的時候，是按照四個位元組的長度從記憶體中獲取物件的物件頭資料，所以你會看到64位的Mark Word會拆成兩行（兩個4位元組）列印出來，
幾個問題
看到這里的時候，腦海里不禁冒出幾個問題，
Q1：為什么Klass pointer只有四個位元組呢？
因為JVM默認開啟了+UseCompressedOops選項，所以Klass Pointer被壓縮成了32位，如果在啟動時配置了-UseCompressedOops選項，那么Klass Pointer就也是64位啦，
Q2：說好了Mark Word的最后兩位是鎖狀態，這剛創建的物件，最后兩位怎么就是00了呢？
這個就要和位元組存盤的大小端模式有關了，
舉個例子，一個16進制的整數0x12345678，對應的二進制整數為：00010010 00110100 01010110 01111000（12 34 56 78），一共占用四個位元組，那么在記憶體中應該如何存盤這長度為4byte的位元組序列的資料呢？
有兩種方式：
- 按照記憶體地址的順序，依次保存12 34 56 78這四個位元組的資料，這種將位元組序列的高序位元組存盤在記憶體的起始地址上的方式，叫大端模式，
- 按照記憶體地址的順序，依次保存78 56 34 12這四個位元組的資料，這種將位元組序列的低序位元組存盤在記憶體的起始地址上的方式，叫小端模式，
而一般我們用的x86或者ARM的CPU，采用的都是小端模式來保存記憶體中的位元組序列，所以和我們常見的順序是反著的，因此，你看到的輸出的前兩行的物件頭，實際上的值是這樣的：
所以物件初始化后，就是無鎖狀態啦，
分析不同狀態時的物件頭
剛才已經就剛初始化的物件分析過一次記憶體布局了，而在鎖狀態不同的情況下，變化也只限于物件頭中Mark Word的值變動，所以這里就快速的分析一下其余的四種狀態時的Mark Word了，這里我也自動將輸出的小端格式轉換成正常的順序來分析，也是通過實際情況來回顧驗證一下剛才的理論知識啦，對照前面的圖片中不同的顏色比對就可以了，
1.gc一次之后的Mark Word
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00001001
紅色的01代表無鎖狀態，藍色的0代表無偏向鎖，黃色的0001是GC分代年齡，因為GC過一次，該物件沒有被回收，年齡加1，
2.加鎖時的Mark Word
00000000 00000000 00000000 00000001 01101101 00001011 10011001 10010000
紅色的00代表輕量級鎖狀態，綠色的一串是指向持有鎖的執行緒的堆疊幀中鎖記錄的指標，
3.競爭鎖時的Mark Word
00000000 00000000 00000000 00000001 00100000 00000000 11011001 01100010
紅色的10代表重量級鎖狀態，綠色的一串是指向重量級鎖Monitor的指標，
4.計算完hashCode的Mark Word
00000000 00000000 00000000 01010110 10101010 11000001 01100011 00001001
紅色的01代表此時回歸到無鎖狀態，，藍色的0代表無偏向鎖，黃色的0001是GC分代年齡為1，紫色這一串是剛才計算的hashCode，保存在了這里，所以只有在呼叫了hashCode()方法時，JVM才會把物件的hashCode保存到物件頭中，
總結
好啦，總結一下，
本篇文章先是介紹了Java物件的記憶體布局（由物件頭、實體資料、對齊填充三部分組成）；之后詳細的介紹了物件頭的資料結構（Mark Word、Klass Pointer、陣列長度），以及不同鎖狀態下（01無鎖、00輕量級鎖、10重量級鎖、11GC標記），Mark Word中的資料格式以及代表的含義；最后通過JOL列印出物件的記憶體布局，進一步驗證了前半部分枯燥的理論知識，
希望看到這里，能讓你徹底的理解Java物件在記憶體中的完整樣貌啦~
參考資料
- markOop.hpp原始碼，主要在注釋中
- objectWaiter.hpp原始碼
- 《深入理解Java虛擬機》
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/458470.html
標籤：Java