速讀原著-HotSpot虛擬機對象探秘

• 2020 年 2 月 14 日
• 筆記

HotSpot 虛擬機對象探秘

對象的創建

Java 是一門面向對象的程式語言，Java 程式運行過程中每時每刻都有對象被創建出來。在語言 層面上，創建對象通常（例外：克隆、反序列化）僅僅是一個 new 關鍵字而已，而在虛擬機中， 對象（本文中討論的對象限於普通 Java 對象，不包括數組和 Class 對象等）的創建又是怎樣一個過程呢？ 虛擬機遇到一條 new 指令時，首先將去檢查這個指令的參數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已被載入、解析和初始化過的。如果沒有，那必須先執行相應的類載入過程。

在類載入通過後，接下來虛擬機將為新生對象分配記憶體。對象所需記憶體的大小在類載入完成後 便可完全確定（如何確定在下一節對象記憶體布局時再詳細講解），為對象分配空間的任務具體 便等同於一塊確定大小的記憶體從 Java 堆中劃分出來，怎麼劃呢？假設 Java 堆中記憶體是絕對規整的，所有用過的記憶體都被放在一邊，空閑的記憶體被放在另一邊，中間放著一個指針作為分界點 的指示器，那所分配記憶體就僅僅是把那個指針向空閑空間那邊挪動一段與對象大小相等的距離， 這種分配方式稱為「指針碰撞」（Bump The Pointer）。如果Java 堆中的記憶體並不是規整的，已被 使用的記憶體和空閑的記憶體相互交錯，那就沒有辦法簡單的進行指針碰撞了，虛擬機就必須維護 一個列表，記錄上哪些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給 對象實例，並更新列表上的記錄，這種分配方式稱為「空閑列表」（Free List）。選擇哪種分配方式由 Java 堆是否規整決定，而 Java 堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。因此在使用 Serial、ParNew 等帶 Compact 過程的收集器時，系統採用的分配演算法是指針碰撞，而使用 CMS 這種基於 Mark-Sweep 演算法的收集器時（說明一下，CMS 收集器可以通過UseCMSCompactAtFullCollection 或 CMSFullGCsBeforeCompaction 來整理記憶體），就通常採用空閑列表。

除如何劃分可用空間之外，還有另外一個需要考慮的問題是對象創建在虛擬機中是非常頻繁的行為，即使是僅僅修改一個指針所指向的位置，在並發情況下也並不是執行緒安全的，可能出現正在給對象 A 分配記憶體，指針還沒來得及修改，對象 B 又同時使用了原來的指針來分配記憶體。解決這個問題有兩個方案，一種是對分配記憶體空間的動作進行同步——實際上虛擬機是採用CAS 配上失敗重試的方式保證更新操作的原子性；另外一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在 Java 堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝， （TLAB ，Thread Local Allocation Buffer），哪個執行緒要分配記憶體，就在哪個執行緒的 TLAB 上分配，只有 TLAB 用完，分配新的 TLAB 時才需要同步鎖定。虛擬機是否使用 TLAB，可以通過- XX:+/-UseTLAB 參數來設定。

記憶體分配完成之後，虛擬機需要將分配到的記憶體空間都初始化為零值（不包括對象頭），如果 使用 TLAB 的話，這一個工作也可以提前至 TLAB 分配時進行。這步操作保證了對象的實例欄位在 Java 程式碼中可以不賦初始值就直接使用，程式能訪問到這些欄位的數據類型所對應的零值。

接下來，虛擬機要對對象進行必要的設置，例如這個對象是哪個類的實例、如何才能找到類的元數據資訊、對象的哈希碼、對象的 GC 分代年齡等資訊。這些資訊存放在對象的對象頭

（Object Header）之中。根據虛擬機當前的運行狀態的不同，如是否啟用偏向鎖等，對象頭會有不同的設置方式。關於對象頭的具體內容，在下一節再詳細介紹。

在上面工作都完成之後，在虛擬機的視角來看，一個新的對象已經產生了。但是在 Java 程式的視角看來，對象創建才剛剛開始——方法還沒有執行，所有的欄位都為零呢。所以一般來說（由位元組碼中是否跟隨有 invokespecial 指令所決定），new 指令之後會接著就是執行方法，把對象按照程式設計師的意願進行初始化，這樣一個真正可用的對象才算完全產生出來。

下面程式碼是 HotSpot 虛擬機 bytecodeInterpreter.cpp 中的程式碼片段（這個解釋器實現很少機會實際使用，大部分平台上都使用模板解釋器；當程式碼通過 JIT 編譯器執行時差異就更大了。不過這段程式碼用於了解HotSpot 的運作過程是沒有什麼問題的）。

程式碼清單 1：HotSpot 解釋器程式碼片段

    // 確保常量池中存放的是已解釋的類    if(!constants->        tag_at(index).        is_unresolved_klass())        {    // 斷言確保是 klassOop 和 instanceKlassOop（這部分下一節介紹） oop entry = (klassOop) *constants->obj_at_addr(index);          assert (entry -> is_klass(),"Should be resolved klass");          klassOop k_entry = (klassOop) entry;          assert (k_entry -> klass_part()->oop_is_instance(), "Should be instanceKlass");          instanceKlass * ik = (instanceKlass *) k_entry -> klass_part();  // 確保對象所屬類型已經經過初始化階段            if (ik -> is_initialized() && ik -> can_be_fastpath_allocated()) {    // 取對象長度              size_t obj_size = ik -> size_helper();              oop result = NULL;          }  // 記錄是否需要將對象所有欄位置零值            bool need_zero = !ZeroTLAB;    // 是否在 TLAB 中分配對象            if (UseTLAB) {                result = (oop) THREAD -> tlab().allocate(obj_size);            }            if (result == NULL) {              need_zero = true;  // 直接在 eden 中分配對象                retry:                HeapWord * compare_to = *Universe::heap () -> top_addr();              HeapWord * new_top = compare_to + obj_size;  // cmpxchg 是 x86 中的 CAS 指令，這裡是一個 C++方法，通過 CAS 方式分配空間，並發失敗的話， 轉到 retry 中重試直至成功分配為止                if (new_top <= *Universe::heap () -> end_addr()){                    if (Atomic::cmpxchg_ptr (new_top, Universe::heap() -> top_addr(), compare_to) !=compare_to){    goto retry;                    }                    result = (oop) compare_to;                }            }            if (result != NULL) {    // 如果需要，為對象初始化零值                if (need_zero) {                    HeapWord * to_zero = (HeapWord *) result + sizeof(oopDesc) / oopSize;                  obj_size -= sizeof(oopDesc) / oopSize;                  if (obj_size > 0) {                        memset(to_zero, 0, obj_size * HeapWordSize);                    }                }// 根據是否啟用偏向鎖，設置對象頭資訊                if (UseBiasedLocking) {                    result -> set_mark(ik -> prototype_header());                } else {                    result -> set_mark(markOopDesc::prototype ());                }                result -> set_klass_gap(0);              result -> set_klass(k_entry);  // 將對象引用入棧，繼續執行下一條指令                SET_STACK_OBJECT(result, 0);                UPDATE_PC_AND_TOS_AND_CONTINUE(3, 1);            }        }

對象的記憶體布局

HotSpot 虛擬機中，對象在記憶體中存儲的布局可以分為三塊區域：對象頭（Header）、實例數據 （Instance Data）和對齊填充（Padding）。

HotSpot 虛擬機的對象頭包括兩部分資訊，第一部分用於存儲對象自身的運行時數據，如哈希碼 （HashCode）、GC 分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒 ID、偏向時間戳等等， 這部分數據的長度在 32 位和 64 位的虛擬機（暫不考慮開啟壓縮指針的場景）中分別為 32 個和64 個 Bits，官方稱它為「Mark Word」。對象需要存儲的運行時數據很多，其實已經超出了 32、

64 位Bitmap 結構所能記錄的限度，但是對象頭資訊是與對象自身定義的數據無關的額外存儲成本，考慮到虛擬機的空間效率，Mark Word 被設計成一個非固定的數據結構以便在極小的空間記憶體儲盡量多的資訊，它會根據對象的狀態復用自己的存儲空間。例如在 32 位的 HotSpot 虛擬機中對象未被鎖定的狀態下，Mark Word 的 32 個 Bits 空間中的 25Bits 用於存儲對象哈希碼（HashCode），4Bits 用於存儲對象分代年齡，2Bits 用於存儲鎖標誌位，1Bit 固定為 0，在其他狀態（輕量級鎖定、重量級鎖定、GC 標記、可偏向）下對象的存儲內容如下表所示。

表 1 HotSpot 虛擬機對象頭 Mark Word

對象頭的另外一部分是類型指針，即是對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。並不是所有的虛擬機實現都必須在對象數據上保留類型指針， 換句話說查找對象的元數據資訊並不一定要經過對象本身，這點我們在下一節討論。另外，如果對象是一個 Java 數組，那在對象頭中還必須有一塊用於記錄數組長度的數據，因為虛擬機可以通過普通Java 對象的元數據資訊確定 Java 對象的大小，但是從數組的元數據中無法確定數組的大小。

以下是HotSpot 虛擬機 markOop.cpp 中的程式碼（注釋）片段，它描述了 32bits 下 MarkWord 的存儲狀態：

// Bit-format of an object header (most significant first, big endian layout below):    //    // 32 bits:    // --------    // hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object)    // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object)    // size:32 ------------------------------------------>| (CMS free block)    // PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)

接下來實例數據部分是對象真正存儲的有效資訊，也既是我們在程式程式碼裡面所定義的各種類型的欄位內容，無論是從父類繼承下來的，還是在子類中定義的都需要記錄襲來。這部分的存儲順序會受到虛擬機分配策略參數（FieldsAllocationStyle）和欄位在 Java 源碼中定義順序的影響。HotSpot 虛擬機默認的分配策略為 longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers），從分配策略中可以看出，相同寬度的欄位總是被分配到一起。在滿足這個前提條件的情況下，在父類中定義的變數會出現在子類之前。如果CompactFields 參數值為 true（默認為 true），那子類之中較窄的變數也可能會插入到父類變數的空隙之中。

第三部分對齊填充並不是必然存在的，也沒有特別的含義，它僅僅起著佔位符的作用。由於HotSpot VM 的自動記憶體管理系統要求對象起始地址必須是 8 位元組的整數倍，換句話說就是對象的大小必須是 8 位元組的整數倍。對象頭部分正好似 8 位元組的倍數（1 倍或者 2 倍），因此當對象實例數據部分沒有對齊的話，就需要通過對齊填充來補全。

對象的訪問定位

建立對象是為了使用對象，我們的 Java 程式需要通過棧上的 reference 數據來操作堆上的具體對象。由於 reference 類型在 Java 虛擬機規範裡面只規定了是一個指向對象的引用，並沒有定義這

個引用應該通過什麼種方式去定位、訪問到堆中的對象的具體位置，對象訪問方式也是取決於虛擬機實現而定的。主流的訪問方式有使用句柄和直接指針兩種。

• 如果使用句柄訪問的話，Java 堆中將會劃分出一塊記憶體來作為句柄池，reference 中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據的具體各自的地址資訊。如圖 1 所示。

• 如果使用直接指針訪問的話，Java 堆對象的布局中就必須考慮如何放置訪問類型數據的相關資訊，reference 中存儲的直接就是對象地址，如圖 2 所示。

這兩種對象訪問方式各有優勢，使用句柄來訪問的最大好處就是 reference 中存儲的是穩定句柄地址，在對象被移動（垃圾收集時移動對象是非常普遍的行為）時只會改變句柄中的實例數據指針，而 reference 本身不需要被修改。 使用直接指針來訪問最大的好處就是速度更快，它節省了一次指針定位的時間開銷，由於對象訪問的在 Java 中非常頻繁，因此這類開銷積小成多也是一項非常可觀的執行成本。從上一部分講解的對象記憶體布局可以看出，就虛擬機 HotSpot 而言，它是使用第二種方式進行對象訪問， 但在整個軟體開發的範圍來看，各種語言、框架中使用句柄來訪問的情況也十分常見。