Java技術JVM研究中HotSpot虛擬機對象的示例分析

這期內容當中小編將會給大家帶來有關Java技術JVM研究中HotSpot虛擬機對象的示例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

對象的創建

語言層面上，創建對象通常（例外：克隆、反序列化）僅僅是一個 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 的運作過程是沒有什么問題的）。

// 確保常量池中存放的是已解釋的類 
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 標記、可偏向）下對象的存儲內容如下表所示。

虛擬機對象頭

| 類型 | 32位JVM | 64位JVM|
| ------ ---- | ------------| --------- |
| markword | 32bit | 64bit |
| 類型指針 | 32bit |64bit ，開啟指針壓縮時為32bit |
| 數組長度 | 32bit |32bit |

1. 開啟指針壓縮時，markword占用8bytes,類型指針占用8bytes，共占用16bytes;

2. 未開啟指針壓縮時，markword占用8bytes,類型指針占用4bytes,但由于java內存地址按照8bytes對齊,長度必須是8的倍數，因此會從12bytes補全到16bytes;

• 數組長度為4bytes,同樣會進行對齊，補足到8bytes;

• 如果對象沒有重寫hashcode方法，那么默認是調用os::random產生hashcode,可以通過System.identityHashCode獲取；os::random產生

• hashcode的規則為:next_rand = (16807seed) mod (2*31-1),因此可以使用31位存儲;另外一旦生成了hashcode,JVM會將其記錄在markword中；

• GC年齡采用4位bit存儲，最大為15，例如MaxTenuringThreshold參數默認值就是15；

• 當處于輕量級鎖、重量級鎖時，記錄的對象指針，根據JVM的說明，此時認為指針仍然是64位，最低兩位假定為0;當處于偏向鎖時，記錄的為獲得偏向鎖的線程指針，該指針也是64位；

標記字段

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)

64 bits:

  unused:25 hash:31 -->| unused:1   age:4    biased_lock:1 lock:2 (normal object)
  JavaThread*:54 epoch:2 unused:1   age:4    biased_lock:1 lock:2 (biased object)
  PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
  size:64 ----------------------------------------------------->| (CMS free block)

 unused:25 hash:31 -->| cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && normal object)
 JavaThread*:54 epoch:2 cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && biased object)
 narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
 unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)

類型指針

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

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

實例數據

接下來實例數據部分是對象真正存儲的有效信息，也既是我們在程序代碼里面所定義的各種類型的字段內容，無論是從父類繼承下來的，還是在子類中定義的都需要記錄襲來。

這部分的存儲順序會受到虛擬機分配策略參數（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 而言，它是使用第二種方式進行對象訪問，但在整個軟件開發的范圍來看，各種語言、框架中使用句柄來訪問的情況也十分常見。

上述就是小編為大家分享的Java技術JVM研究中HotSpot虛擬機對象的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。