java之HotSpot虛擬機

時間 2019-11-19

原文原文鏈接

本文轉自，周志明——HotSpot虛擬機對象探祕html

請讀者首先注意本篇的題目中的限定語「HotSpot 虛擬機」，在虛擬機規範中明確寫道：「全部在虛擬機規範之中沒有明確描述的實現細節，都不該成爲虛擬機設計者發揮創造性的牽絆，設計者能夠徹底自主決定全部規範中未曾描述的虛擬機內部細節，例如：運行時數據區的內存如何佈局、選用哪一種垃圾收集的算法等」。所以，本篇（整個內存篇中全部的文章）的內容會涉及到虛擬機「自主決定」的實現，咱們的討論將在 HotSpot VM 的範圍內展開。同時，我也假定讀者已經理解了虛擬機規範中所定義的 JVM 公共內存模型，例如運行時數據區域、棧幀結構等基礎知識，若是讀者對這些內容有疑問，能夠先閱讀《Java 虛擬機規範（JavaSE 7 Editon）》[1]第 2 章或《深刻理解 Java 虛擬機：JVM 高級特性與最佳實踐》[2]的第二、3 章相關內容。java

對象的建立

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

虛擬機遇到一條 new 指令時，首先將去檢查這個指令的參數是否能在常量池中定位到一個類的符號引用，而且檢查這個符號引用表明的類是否已被加載、解析和初始化過的。若是沒有，那必須先執行相應的類加載過程。程序員

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

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

內存分配完成以後，虛擬機須要將分配到的內存空間都初始化爲零值（不包括對象頭），若是使用 TLAB 的話，這一個工做也能夠提早至 TLAB 分配時進行。這步操做保證了對象的實例字段在 Java 代碼中能夠不賦初始值就直接使用，程序能訪問到這些字段的數據類型所對應的零值。編程

接下來，虛擬機要對對象進行必要的設置，例如這個對象是哪一個類的實例、如何才能找到類的元數據信息、對象的哈希碼、對象的 GC 分代年齡等信息。這些信息存放在對象的對象頭（Object Header）之中。根據虛擬機當前的運行狀態的不一樣，如是否啓用偏向鎖等，對象頭會有不一樣的設置方式。關於對象頭的具體內容，在下一節再詳細介紹。數組

在上面工做都完成以後，在虛擬機的視角來看，一個新的對象已經產生了。可是在 Java 程序的視角看來，對象建立纔剛剛開始——<init> 方法尚未執行，全部的字段都爲零呢。因此通常來講（由字節碼中是否跟隨有 invokespecial 指令所決定），new 指令以後會接着就是執行 <init> 方法，把對象按照程序員的意願進行初始化，這樣一個真正可用的對象纔算徹底產生出來。安全

下面代碼是 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」。對象須要存儲的運行時數據不少，其實已經超出了 3二、64 位 Bitmap 結構所能記錄的限度，可是對象頭信息是與對象自身定義的數據無關的額外存儲成本，考慮到虛擬機的空間效率，Mark Word 被設計成一個非固定的數據結構以便在極小的空間內存儲儘可能多的信息，它會根據對象的狀態複用本身的存儲空間。例如在 32 位的 HotSpot 虛擬機中對象未被鎖定的狀態下，Mark Word 的 32 個 Bits 空間中的 25Bits 用於存儲對象哈希碼（HashCode），4Bits 用於存儲對象分代年齡，2Bits 用於存儲鎖標誌位，1Bit 固定爲 0，在其餘狀態（輕量級鎖定、重量級鎖定、GC 標記、可偏向）下對象的存儲內容以下表所示。

表 1 HotSpot 虛擬機對象頭 Mark Word

存儲內容	標誌位	狀態
對象哈希碼、對象分代年齡	01	未鎖定
指向鎖記錄的指針	00	輕量級鎖定
指向重量級鎖的指針	10	膨脹（重量級鎖定）
空，不須要記錄信息	11	GC 標記
偏向線程 ID、偏向時間戳、對象分代年齡	01	可偏向

對象頭的另一部分是類型指針，便是對象指向它的類元數據的指針，虛擬機經過這個指針來肯定這個對象是哪一個類的實例。並非全部的虛擬機實現都必須在對象數據上保留類型指針，換句話說查找對象的元數據信息並不必定要通過對象自己，這點咱們在下一節討論。另外，若是對象是一個 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 虛擬機規範裏面只規定了是一個指向對象的引用，並無定義這個引用應該經過什麼種方式去定位、訪問到堆中的對象的具體位置，對象訪問方式也是取決於虛擬機實現而定的。主流的訪問方式有使用句柄和直接指針兩種。

圖 1 經過句柄訪問對象

圖 2 經過直接指針訪問對象

若是使用句柄訪問的話，Java 堆中將會劃分出一塊內存來做爲句柄池，reference 中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據的具體各自的地址信息。如圖 1 所示。
若是使用直接指針訪問的話，Java 堆對象的佈局中就必須考慮如何放置訪問類型數據的相關信息，reference 中存儲的直接就是對象地址，如圖 2 所示。

這兩種對象訪問方式各有優點，使用句柄來訪問的最大好處就是 reference 中存儲的是穩定句柄地址，在對象被移動（垃圾收集時移動對象是很是廣泛的行爲）時只會改變句柄中的實例數據指針，而 reference 自己不須要被修改。

使用直接指針來訪問最大的好處就是速度更快，它節省了一次指針定位的時間開銷，因爲對象訪問的在 Java 中很是頻繁，所以這類開銷積小成多也是一項很是可觀的執行成本。從上一部分講解的對象內存佈局能夠看出，就虛擬機 HotSpot 而言，它是使用第二種方式進行對象訪問，但在整個軟件開發的範圍來看，各類語言、框架中使用句柄來訪問的狀況也十分常見。