深入理解Java虛擬機器讀書筆記(2): 深入理解HotSpot虛擬機器物件

為了理解虛擬機器中資料的細節，比如如何建立、如何佈局以及如何訪問，必須具體到某一虛擬機器和某一個記憶體區域。此處深入探討HotSpot虛擬機器在Java堆中物件分配、佈局和訪問的全過程。

一、物件的建立

反映到Java語言中，物件的建立通常不過是一個new關鍵字，然而反映到底層虛擬機器上是如何呢？可以概括為以下三步：

• 類載入： 虛擬機器遇到一個new指令時，首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已被載入、 解析和初始化過

  。 如果沒有，那必須先執行相應的類載入過程。

• 分配記憶體： 類載入通過後，虛擬機器為新生物件分配記憶體。物件所需記憶體的大小在類載入完成後便可完全確定，為物件分配空間的任務等同於把一塊確定大小的記憶體從Java堆中劃分出來。 這裡一般有兩種劃分方式：

  • Java堆中記憶體是絕對規整的，所有用過的記憶體都放在一邊，空閒的記憶體放在另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是把那個指標向空閒空間那邊挪動一段與物件大小相等的距離，這種分配方式稱為“指標碰撞”(Bump the Pointer)。
  • Java堆中記憶體並不是規整的，已使用的記憶體和空閒的記憶體相互交錯，那就沒有辦法簡單地進行指標碰撞了，虛擬機器就必須維護一個列表，記錄哪些記憶體塊是可用的
    ，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空閒列表”（Free List）。

  選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。 因此，在使用Serial、 ParNew等帶Compact過程的收集器時，系統採用的分配演算法是指標碰撞，而使用CMS這種基於Mark-Sweep演算法的收集器時，通常採用空閒列表。

  在分配記憶體時，另外一個需要考慮的問題是執行緒安全性。物件建立時一個非常頻繁的行為，即使是僅僅修改一個指標所指向的位置，在併發情況下也並不是執行緒安全的。例如可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的情況。 針對此問題有兩種解決方案：

  • 對分配記憶體空間的動作進行同步處理：即虛擬機器採用CAS+失敗重試的方式保證更新操作的原子性
  • 把記憶體分配的動作按照執行緒劃分在不同得空間中進行，即每個執行緒在Java堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝（Thread Local Allocation Buffer,TLAB） 。這有點類似於執行緒封閉技術，哪個執行緒要分配記憶體，就在哪個執行緒的TLAB上分配，只有TLAB用完並分配新的TLAB時，才需要同步鎖定。虛擬機器是否使用TLAB，可以通過-XX：+/-UseTLAB引數來設定。

• 初始化： 記憶體分配完成後，需要對分配到的記憶體空間都進行初始化為零值（不包括物件頭），如果使用TLAB，這一工作過程也可以提前至TLAB分配時進行。 這一步的動作，保證了物件的例項欄位在Java程式碼中可以不賦初值就可以直接使用，程式能訪問到這些欄位的資料型別所對應的零值。

• 物件頭設定：上面的初始化僅僅是通用的設定並且不包括物件頭的設定，虛擬機器接下來還要對物件進行更加豐富的設定，例如這個物件是哪個類的例項、 如何才能找到類的元資料資訊、 物件的雜湊碼、 物件的GC分代年齡等資訊。 這些資訊存放在物件的物件頭（Object Header）之中。 根據虛擬機器當前的執行狀態的不同，如是否啟用偏向鎖等，物件頭會有不同的設定方式。

• 物件init： 完成上面的工作以後，在虛擬機器中其實一個物件已經產生了，但是從Java程式碼來看，其實方法還沒有執行，此時所有的欄位還停留在初始化時設定的零值。一般來說（由位元組碼中是否跟隨invokespecial指令所決定），執行new指令之後會接著執行＜init＞方法，把物件按照程式設計師的意願進行初始化，這樣一個真正可用的物件才算完全產生出來。

至此，一個物件建立完成。那麼，物件在記憶體中又是如何佈局的呢？

二、物件的記憶體佈局

在HotSpot虛擬機器中，物件在記憶體中儲存的佈局可以分為3塊區域：物件頭（Header）、例項資料（Instance Data）和對齊填充（Padding）。

2.1 物件頭

物件頭包括兩部分資訊，即物件執行時資訊和型別指標。

第一部分用於儲存物件自身的執行時資料，如雜湊碼（HashCode）、GC分代年齡、 鎖狀態標誌、 執行緒持有的鎖、 偏向執行緒ID、 偏向時間戳等，這部分資料的長度在32位和64位的虛擬機器（未開啟壓縮指標）中分別為32bit和64bit，官方稱它為“Mark Word”。 物件頭資訊是與物件自身定義的資料無關的額外儲存成本，考慮到虛擬機器的空間效率，Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲儘量多的資訊，它會根據物件的狀態複用自己的儲存空間。

物件頭的另外一部分是型別指標，即物件指向它的類元資料的指標，虛擬機器通過這個指標來確定這個物件是哪個類的例項。 並不是所有的虛擬機器實現都必須在物件資料上保留型別指標，換句話說，查詢物件的元資料資訊並不一定要經過物件本身。另外，如果物件是一個Java陣列，那在物件頭中還必須有一塊用於記錄陣列長度的資料，因為虛擬機器可以通過普通Java物件的元資料資訊確定Java物件的大小，但是從陣列的元資料中卻無法確定陣列的大小。

2.2 例項資料

例項資料部分是物件真正儲存的有效資訊，也是在程式程式碼中所定義的各種型別的欄位內容，包括子類和父類的。關於儲存順序，受到虛擬機器分配策略引數和欄位在原始碼中定義順序的影響。一般來說，相同寬度的欄位總是被分配到一起，在此前提下，父類中定義的變數會出現在子類之前。如果CompactFields引數值為true（預設為true），那麼子類之中較窄的變數也可能會插入到父類變數的空隙之中。

2.3 對齊填充

這一部分不是必然存在的，僅僅起著佔位符的作用，沒有什麼實際含義。由於HotSpot VM的自動記憶體管理系統要求物件起始地址必須是8位元組的整數倍，換句話說，就是物件的大小必須是8位元組的整數倍。 而物件頭部分正好是8位元組的倍數（1倍或者2倍），因此，當物件例項資料部分沒有對齊時，就需要通過對齊填充來補全。

三、物件的訪問

Java程式通過棧上的reference資料來操作堆上的具體物件。由於reference型別在Java虛擬機器規範中只規定了一個指向物件的引用，並沒有定義這個引用應該通過何種方式去定位、 訪問堆中的物件的具體位置，所以物件訪問方式也是取決於虛擬機器實現而定的。 目前主流的訪問方式有使用控制代碼和直接指標兩種。 關於控制代碼，可以參考知乎的這個話題控制代碼是什麼？

控制代碼訪問

如果使用控制代碼訪問，Java堆中會劃分出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料各自的具體地址資訊。如下圖所示：

直接指標訪問

如果使用直接指標訪問，那麼Java堆物件的佈局中就必須考慮如何放置訪問型別資料的相關資訊，而reference中儲存的直接就是物件地址，如下圖所示：

這兩種物件訪問方式各有優勢，使用控制代碼來訪問的最大好處就是reference中儲存的是穩定的控制代碼地址，在物件被移動（垃圾收集時移動物件是非常普遍的行為）時只會改變控制代碼中的例項資料指標，而reference本身不需要修改。 使用直接指標訪問方式的最大好處就是速度更快，它節省了一次指標定位的時間開銷，由於物件的訪問在Java中非常頻繁，因此這類開銷積少成多後也是一項非常可觀的執行成本。

對於Hotspot而言，使用的是直接指標訪問。