2.3 HotSpot虛擬機對象探秘

介紹完Java虛擬機的運行時數據區域之后，我們大致明白了Java虛擬機內存模型的概況，相信讀者了解過內存中放了什么，也許就會更進一步想了解這些虛擬機內存中數據的其他細節，譬如它們是如何創建、如何布局以及如何訪問的。對于這樣涉及細節的問題，必須把討論范圍限定在具體的虛擬機和集中在某一個內存區域上才有意義。基于實用優先的原則，筆者以最常用的虛擬機HotSpot和最常用的內存區域Java堆為例，深入探討一下HotSpot虛擬機在Java堆中對象分配、布局和訪問的全過程。

2.3.1 對象的創建

Java是一門面向對象的編程語言，Java程序運行過程中無時無刻都有對象被創建出來。在語言層面上，創建對象通常（例外：復制、反序列化）僅僅是一個new關鍵字而已，而在虛擬機中，對象（文中討論的對象限于普通Java對象，不包括數組和Class對象等）的創建又是怎樣一個過程呢？

當Java虛擬機遇到一條字節碼new指令時，首先將去檢查這個指令的參數是否能在常量池中定位到一個類的符號引用，并且檢查這個符號引用代表的類是否已被加載、解析和初始化過。如果沒有，那必須先執行相應的類加載過程，本書第7章將探討這部分細節。

在類加載檢查通過后，接下來虛擬機將為新生對象分配內存。對象所需內存的大小在類加載完成后便可完全確定（如何確定將在2.3.2節中介紹），為對象分配空間的任務實際上便等同于把一塊確定大小的內存塊從Java堆中劃分出來。假設Java堆中內存是絕對規整的，所有被使用過的內存都被放在一邊，空閑的內存被放在另一邊，中間放著一個指針作為分界點的指示器，那所分配內存就僅僅是把那個指針向空閑空間方向挪動一段與對象大小相等的距離，這種分配方式稱為“指針碰撞”（Bump The Pointer）。但如果Java堆中的內存并不是規整的，已被使用的內存和空閑的內存相互交錯在一起，那就沒有辦法簡單地進行指針碰撞了，虛擬機就必須維護一個列表，記錄上哪些內存塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給對象實例，并更新列表上的記錄，這種分配方式稱為“空閑列表”（Free List）。選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整又由所采用的垃圾收集器是否帶有空間壓縮整理（Compact）的能力決定。因此，當使用Serial、ParNew等帶壓縮整理過程的收集器時，系統采用的分配算法是指針碰撞，既簡單又高效；而當使用CMS這種基于清除（Sweep）算法的收集器時，理論上就只能采用較為復雜的空閑列表來分配內存。

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

內存分配完成之后，虛擬機必須將分配到的內存空間（但不包括對象頭）都初始化為零值，如果使用了TLAB的話，這一項工作也可以提前至TLAB分配時順便進行。這步操作保證了對象的實例字段在Java代碼中可以不賦初始值就直接使用，使程序能訪問到這些字段的數據類型所對應的零值。

接下來，Java虛擬機還要對對象進行必要的設置，例如這個對象是哪個類的實例、如何才能找到類的元數據信息、對象的哈希碼（實際上對象的哈希碼會延后到真正調用Object::hashCode()方法時才計算）、對象的GC分代年齡等信息。這些信息存放在對象的對象頭（Object Header）之中。根據虛擬機當前運行狀態的不同，如是否啟用偏向鎖等，對象頭會有不同的設置方式。關于對象頭的具體內容，稍后會詳細介紹。

在上面工作都完成之后，從虛擬機的視角來看，一個新的對象已經產生了。但是從Java程序的視角看來，對象創建才剛剛開始——構造函數，即Class文件中的<init>()方法還沒有執行，所有的字段都為默認的零值，對象需要的其他資源和狀態信息也還沒有按照預定的意圖構造好。一般來說（由字節碼流中new指令后面是否跟隨invokespecial指令所決定，Java編譯器會在遇到new關鍵字的地方同時生成這兩條字節碼指令，但如果直接通過其他方式產生的則不一定如此），new指令之后會接著執行<init>()方法，按照程序員的意愿對對象進行初始化，這樣一個真正可用的對象才算完全被構造出來。

下面代碼清單2-1是HotSpot虛擬機字節碼解釋器（bytecodeInterpreter.cpp）中的代碼片段。這個解釋器實現很少有機會實際使用，大部分平臺上都使用模板解釋器；當代碼通過即時編譯器執行時差異就更大了。不過這段代碼（以及筆者添加的注釋）用于了解HotSpot的運作過程是沒有什么問題的。

代碼清單2-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);
        }
    }
}

2.3.2 對象的內存布局

在HotSpot虛擬機里，對象在堆內存中的存儲布局可以劃分為三個部分：對象頭（Header）、實例數據（Instance Data）和對齊填充（Padding）。

HotSpot虛擬機對象的對象頭部分包括兩類信息。第一類是用于存儲對象自身的運行時數據，如哈希碼（HashCode）、GC分代年齡、鎖狀態標志、線程持有的鎖、偏向線程ID、偏向時間戳等，這部分數據的長度在32位和64位的虛擬機（未開啟壓縮指針）中分別為32個比特和64個比特，官方稱它為“Mark Word”。對象需要存儲的運行時數據很多，其實已經超出了32、64位Bitmap結構所能記錄的最大限度，但對象頭里的信息是與對象自身定義的數據無關的額外存儲成本，考慮到虛擬機的空間效率，Mark Word被設計成一個有著動態定義的數據結構，以便在極小的空間內存儲盡量多的數據，根據對象的狀態復用自己的存儲空間。例如在32位的HotSpot虛擬機中，如對象未被同步鎖鎖定的狀態下，Mark Word的32個比特存儲空間中的25個比特用于存儲對象哈希碼，4個比特用于存儲對象分代年齡，2個比特用于存儲鎖標志位，1個比特固定為0，在其他狀態（輕量級鎖定、重量級鎖定、GC標記、可偏向）下對象的存儲內容如表2-1所示。

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

代碼清單2-2為HotSpot虛擬機代表Mark Word中的代碼（markOop.cpp）注釋片段，它描述了32位虛擬機Mark Word的存儲布局：

代碼清單2-2 markOop.cpp片段

// 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)

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

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

2.3.3 對象的訪問定位

創建對象自然是為了后續使用該對象，我們的Java程序會通過棧上的reference數據來操作堆上的具體對象。由于reference類型在《Java虛擬機規范》里面只規定了它是一個指向對象的引用，并沒有定義這個引用應該通過什么方式去定位、訪問到堆中對象的具體位置，所以對象訪問方式也是由虛擬機實現而定的，主流的訪問方式主要有使用句柄和直接指針兩種：

·如果使用句柄訪問的話，Java堆中將可能會劃分出一塊內存來作為句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據各自具體的地址信息，其結構如圖2-2所示。

·如果使用直接指針訪問的話，Java堆中對象的內存布局就必須考慮如何放置訪問類型數據的相關信息，reference中存儲的直接就是對象地址，如果只是訪問對象本身的話，就不需要多一次間接訪問的開銷，如圖2-3所示。

這兩種對象訪問方式各有優勢，使用句柄來訪問的最大好處就是reference中存儲的是穩定句柄地址，在對象被移動（垃圾收集時移動對象是非常普遍的行為）時只會改變句柄中的實例數據指針，而reference本身不需要被修改。

使用直接指針來訪問最大的好處就是速度更快，它節省了一次指針定位的時間開銷，由于對象訪問在Java中非常頻繁，因此這類開銷積少成多也是一項極為可觀的執行成本，就本書討論的主要虛擬機HotSpot而言，它主要使用第二種方式進行對象訪問（有例外情況，如果使用了Shenandoah收集器的話也會有一次額外的轉發，具體可參見第3章），但從整個軟件開發的范圍來看，在各種語言、框架中使用句柄來訪問的情況也十分常見。