摘要

本文以如何計算Java物件佔用記憶體大小為切入點，在討論計算Java物件佔用堆記憶體大小的方法的基礎上，詳細討論了Java物件頭格式並結合JDK原始碼對物件頭中的協議欄位做了介紹，涉及記憶體模型、鎖原理、分代GC、OOP-Klass模型等內容。最後推薦JDK自帶的Hotspot Debug工具——HSDB，來檢視物件在記憶體中的具體存在形式，以論證文中所述內容。

背景

目前我們系統的業務程式碼中大量使用了LocalCache的方式做本地快取，而且cache的maxSize通常設的比較大，比如10000。我們的業務系統中就使用了size為10000的15個本地快取，所以最壞情況下將可快取15萬個物件。這會消耗掉不菲的本地堆記憶體，而至於實際上到底應該設多大容量的快取、執行時這大量的本地快取會給堆記憶體帶來多少壓力，實際佔用多少記憶體大小，會不會有較高的快取穿透風險，目前並不方便知悉。考慮到對快取實際佔用記憶體的大小能有個更直觀和量化的參考，需要對執行時指定物件的記憶體佔用進行評估和計算。

要計算Java物件佔用記憶體的大小，首先需要了解Java物件在記憶體中的實際儲存方式和儲存格式。

另一方面，大家都瞭解Java物件的儲存總得來說會佔用JVM記憶體的堆記憶體、棧記憶體及方法區，但由於棧記憶體中存放的資料可以看做是執行時的臨時資料，主要表現為本地變數、運算元、物件引用地址等。這些資料會在方法執行結束後立即回收掉，不會駐留。對儲存空間空間的佔用也只是執行函式指令時所必須的空間。通常不會造成記憶體的瓶頸。而方法區中儲存的則是物件所對應的類資訊、函式表、建構函式、靜態常量等，這些資訊在類載入時(按需)只會在方法區中儲存一份，不會產生額外的儲存空間。因此本文所要討論的主要目標是Java物件對堆記憶體的佔用。

記憶體佔用計算方法

如果讀者關心物件在JVM中的儲存原理，可閱讀本文後邊幾個小節中關於物件儲存原理的介紹。如果不關心物件儲存原理，而只想直接計算記憶體佔用的話，其實並不難，筆者這裡總結了三種方法以供參考：

1. Instrumentation

使用java.lang.instrument.Instrumentation.getObjectSize()方法，可以很方便的計算任何一個執行時物件的大小，返回該物件本身及其間接引用的物件在記憶體中的大小。不過，這個類的唯一實現類InstrumentationImpl的構造方法是私有的，在建立時，需要依賴一個nativeAgent，和執行環境所支援的一些預定義類資訊，我們在程式碼中無法直接例項化它，需要在JVM啟動時，通過指定代理的方式，讓JVM來例項化它。

具體來講，就是需要宣告一個premain方法，它和main方法的方法簽名有點相似，只不過方法名叫“premain”，同時方法引數也不一樣，它接收一個String型別和instrumentation引數，而String引數實際上和String[]是一樣的，只不過用String統一來表達的。在premain函式中，將instrumentation引數賦給一個靜態變數，其它地方就可以使用了。如：

/**
 * @author yepei
 * @date 2018/04/23
 * @description
 */
public class SizeTool { private static Instrumentation instrumentation; public static void premain(String args, Instrumentation inst) { instrumentation = inst; } public static long getObjectSize(Object o) { return instrumentation.getObjectSize(o); } } 

從方法名可以猜到，這裡的premain是要先於main執行的，而先於main執行，這個動作只能由JVM來完成了。即在JVM啟動時，先啟動一個agent，操作如下：

假設main方法所在的jar包為：A.jar，premain方法所在的jar包為B.jar。注意為main所在的程式碼打包時，和其它工具類打包一樣，需要宣告一個MANIFEST.MF清單檔案，如下所求：

Manifest-Version: 1.0
Main-Class: yp.tools.Main Premain-Class: yp.tools.SizeTool 

然後執行java命令執行jar檔案：

java -javaagent:B.jar -jar A.jar 

點評：這種方法的優點是編碼簡單，缺點就是必須啟動一個javaagent，因此要求修改Java的啟動引數。

2. 使用Unsafe

java中的sun.misc.Unsafe類，有一個objectFieldOffset(Field f)方法，表示獲取指定欄位在所在例項中的起始地址偏移量，如此可以計算出指定的物件中每個欄位的偏移量，值為最大的那個就是最後一個欄位的首地址，加上該欄位的實際大小，就能知道該物件整體的大小。如現有一Person類：

class Person{
    int age;
    String name;
    boolean married; } 

假設該類的一個例項p，通過Unsafe.objectFieldOffset()方法計算到得age/birthday/married三個欄位的偏移量分別是16，21, 17，則表明p1物件中的最後一個欄位是name，它的首地址是21，由於它是一個引用，所以它的大小預設為4(開啟指標壓縮)，則該物件本身的大小就是21+4+ 7= 32位元組。其中7表示padding，即為了使結果變成8的整數倍而做的padding。

但上述計算，只是計算了物件本身的大小，並沒有計算其所引用的引用型別的最終大小，這就需要手工寫程式碼進行遞迴計算了。

點評：使用Unsafe可以完全不care物件內的複雜構成，可以很精確的計算出物件頭的大小(即第一個欄位的偏移)及每個欄位的偏移。缺點是Unsafe通常禁止開發者直接使用，需要通過反射獲取其例項，另外，最後一個欄位的大小需要手工計算。其次需要手工寫程式碼遞迴計算才能得到物件及其所引用的物件的綜合大小，相對比較麻煩。

3. 使用第三方工具

這裡要介紹的是lucene提供的專門用於計算堆記憶體佔用大小的工具類：RamUsageEstimator，maven座標：

<dependency>
      <groupId>org.apache.lucene</groupId> <artifactId>lucene-core</artifactId> <version>4.0.0</version> </dependency> 

RamUsageEstimator就是根據java物件在堆記憶體中的儲存格式，通過計算Java物件頭、例項資料、引用等的大小，相加而得，如果有引用，還能遞迴計算引用物件的大小。RamUsageEstimator的原始碼並不多，幾百行，清晰可讀。這裡不進行一一解讀了。它在初始化的時候會根據當前JVM執行環境、CPU架構、執行引數、是否開啟指標壓縮、JDK版本等綜合計算物件頭的大小，而例項資料部分則按照java基礎資料型別的標準大小進行計算。思路簡單，同時也在一定程度上反映出了Java物件格式的奧祕！

常用方法如下：

//計算指定物件及其引用樹上的所有物件的綜合大小，單位位元組
long RamUsageEstimator.sizeOf(Object obj)

//計算指定物件本身在堆空間的大小，單位位元組
long RamUsageEstimator.shallowSizeOf(Object obj)

//計算指定物件及其引用樹上的所有物件的綜合大小，返回可讀的結果，如：2KB String RamUsageEstimator.humanSizeOf(Object obj) 

點評：使用該第三方工具比較簡單直接，主要依靠JVM本身環境、引數及CPU架構計算頭資訊，再依據資料型別的標準計算例項欄位大小，計算速度很快，另外使用較方便。如果非要說這種方式有什麼缺點的話，那就是這種方式計算所得的物件頭大小是基於JVM宣告規範的，並不是通過執行時記憶體地址計算而得，存在與實際大小不符的這種可能性。

Java物件格式

在HotSpot虛擬機器中，Java物件的儲存格式也是一個協議或者資料結構，底層是用C++程式碼定義的。Java物件結構大致如下圖所示——

  image

即，Java物件從整體上可以分為三個部分，物件頭、例項資料和對齊填充

物件頭：Instance Header，Java物件最複雜的一部分，採用C++定義了頭的協議格式，儲存了Java物件hash、GC年齡、鎖標記、class指標、陣列長度等資訊，稍後做出詳細解說。

例項資料：Instance Data，這部分資料才是真正具有業務意義的資料，實際上就是當前物件中的例項欄位。在VM中，物件的欄位是由基本資料型別和引用型別組成的。其所佔用空間的大小如下所示：

  image.png

說明：其中ref表示引用型別，引用型別實際上是一個地址指標，32bit機器上，佔用4位元組，64bit機器上，在jdk1.6之後，如果開啟了指標壓縮(預設開啟: -XX:UseCompressedOops，僅支援64位機器)，則佔用4位元組。Java物件的所有欄位型別都可對映為上述型別之一，因此例項資料部分的大小，實際上就是這些欄位型別的大小之和。當然，實際情況可能比這個稍微複雜一點，如欄位排序、內部padding以及父類欄位大小的計算等。

對齊填充：Padding，VM要求物件大小須是8的整體數，該部分是為了讓整體物件在記憶體中的地址空間大小達到8的整數倍而額外佔用的位元組數。

物件頭

物件頭是理解JVM中物件儲存方式的最核心的部分，甚至是理解java多執行緒、分代GC、鎖等理論的基礎，也是窺探JVM底層諸多實現細節的出發點。做為一個java程式猿，這是不可不瞭解的一部分。那麼這裡提到的物件頭到底是什麼呢？

參考OpenJDK中JVM原始碼部分，對物件頭的C++定義如下：

class oopDesc {
  friend class VMStructs; private: volatile markOop _mark; union _metadata { wideKlassOop _klass; narrowOop _compressed_klass; } _metadata; ... } 

原始碼裡的 _mark 和 _metadata兩個欄位就是物件頭的定義，分別表示物件頭中的兩個基本組成部分，_mark用於儲存hash、gc年齡、鎖標記、偏向鎖、自旋時間等，而_metadata是個共用體(union)，即_klass欄位或_compressed_klass，儲存當前物件到所在class的引用，而這個引用的要麼由“_klass”來儲存，要麼由“_compressed_klass”來儲存，其中_compressed_klass表示壓縮的class指標，即當JVM開啟了 -XX:UseCompressedOops選項時，就表示啟用指標壓縮選項，自然就使用_commpressed_klass來儲存class引用了，否則使用_klass。

注意到，_mark的型別是 markOop，而_metadata的型別是union，_metadata內部兩個欄位：_klass和_compressed_klass型別分別為wideKlassOop和narrowOop，分別表示什麼意思呢？這裡順便說一個union聯合體的概念，這是在C++中的一種結構宣告，類似struct，稱作：“聯合”，它是一種特殊的類，也是一種構造型別的資料結構。在一個“聯合”內可以定義多種不同的資料型別， 一個被說明為該“聯合”型別的變數中，允許裝入該“聯合”所定義的任何一種資料，這些資料共享同一段記憶體，已達到節省空間的目的。由此可見，剛剛所說的使用-XX:UseCompressedOops後，就自動使用_metadata中的_compressed_klass來作為指向當前物件的class引用，它的型別是narrowOop。可以看到，物件頭中的兩個欄位的定義都包含了“Oop”字眼，不難猜出，這是一種在JVM層定義好的“型別”。

OOP-Klass模型

   實際上，Java的面向物件在語言層是通過java的class定義實現的，而在JVM層，也有對應的實現，那就是Oop模型。所謂Oop模型，全稱：`Ordinary Object Pointer`，即普通物件指標。JVM層用於定義Java物件模型及一些元資料格式的模型就是：Oop，可以認為是JVM層中的“類”。通過[JDK原始碼](https://github.com/openjdk-mirror/jdk7u-hotspot/tree/50bdefc3afe944ca74c3093e7448d6b889cd20d1/src/share/vm/oops)可以看到，有很多模型定義的名稱都是以Oop結尾：`arrayOop`/`markOop`/`instanceOop`/`methodOop`/`objectArrayOop`等，什麼意思呢？ HotSpot是基於c++語言實現的，它最核心的地方是設計了兩種模型,分別是`OOP`和`Klass`，稱之為`OOP-Klass Model`. 其中`OOP`用來將指標物件化，比C++底層使用的"`*`"更好用，**每一個型別的OOP都代表一個在JVM內部使用的特定物件的型別**。而`Klass`則用來描述JVM層面中物件例項的具體型別，它是java實現語言層面型別的基礎，或者說是**對java語言層型別的VM層描述**。所以看到openJDK原始碼中的定義基本都以Oop或Klass結尾，如圖所示： 由上述定義可以簡單的說，Oop就是JVM內部物件型別，而Klass就是java類在JVM中的對映。其中關於Oop和Klass體系，參考定義：[https://github.com/openjdk-mirror/jdk7u-hotspot/blob/50bdefc3afe944ca74c3093e7448d6b889cd20d1/src/share/vm/oops/oop.hpp](https://github.com/openjdk-mirror/jdk7u-hotspot/blob/50bdefc3afe944ca74c3093e7448d6b889cd20d1/src/share/vm/oops/oop.hpp)；JVM中把我們上層可見的Java物件在底層實際上表示為兩部分，分別是oop和`klass`，其中`oop`專注於表示物件的例項資料，不關心物件中的例項方法(包括繼承、過載等)所對應的函式表。而klass則維護物件到java class及函式表的功能，它是java class及實現多型的基礎。這裡列舉幾個基礎的Oop和Klass—— 

Oop:

//定義了oops共同基類
typedef class   oopDesc* oop; //表示一個Java型別例項 typedef class instanceOopDesc* instanceOop; //表示一個Java方法 typedef class methodOopDesc* methodOop; //定義了陣列OOPS的抽象基類 typedef class arrayOopDesc* arrayOop; //表示持有一個OOPS陣列 typedef class objArrayOopDesc* objArrayOop; //表示容納基本型別的陣列 typedef class typeArrayOopDesc* typeArrayOop; //表示在Class檔案中描述的常量池 typedef class constantPoolOopDesc* constantPoolOop; //常量池告訴快取 typedef class constantPoolCacheOopDesc* constantPoolCacheOop; //描述一個與Java類對等的C++類 typedef class klassOopDesc* klassOop; //表示物件頭 typedef class markOopDesc* markOop; 

Klass:

//klassOop的一部分，用來描述語言層的型別
class  Klass;
//在虛擬機器層面描述一個Java類 class instanceKlass; //專有instantKlass，表示java.lang.Class的Klass class instanceMirrorKlass; //表示methodOop的Klass class methodKlass; //最為klass鏈的端點，klassKlass的Klass就是它自身 class klassKlass; //表示array型別的抽象基類 class arrayKlass; //表示constantPoolOop的Klass class constantPoolKlass; 

結合上述JVM層與java語言層，java物件的表示關係如下所示：

  image.png
其中 OopDesc是物件例項的基類(Java例項在VM中表現為 instanceOopDesc)，Klass是類資訊的基類(Java類在VM中表現為 instanceKlass)， klassKlass則是對 Klass本身的描述(Java類的 class物件在VM中表現為 klassKlass)。

 

有了對上述結構的認識，對應到記憶體中的儲存區域，那麼物件是怎麼儲存的，就了比較清楚的認識：物件例項(instanceOopDesc)儲存在堆上，物件的元資料(instanceKlass)儲存在方法區，物件的引用則儲存在棧上。

因此，關於本小節，對OOP-Klass Model的討論，可以用一句簡潔明瞭的話來總結其意義：一個Java類在被VM載入時，JVM會為其在方法區建立一個instanceKlass，來表示該類的class資訊。當我們在程式碼中基於此類用new建立一個新物件時，實際上JVM會去堆上建立一個instanceOopDesc物件，該物件保含物件頭markWord和klass指標，klass指標指向方法區中的instanceKlass,markWord則儲存一些鎖、GC等相關的執行時資料。而在堆上建立的這個instanceOopDesc所對應的地址會被用來建立一個引用，賦給當前執行緒執行時棧上的一個變數。

關於Mark Word

mark word是物件頭中較為神祕的一部分，也是本文講述的重點，JDK oop.hpp原始碼檔案中，有幾行重要的註釋，揭示了32位機器和64位機器下，物件頭的格式：

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

在oop.hpp原始碼檔案中，有對Oop基類中mark word結構的定義，如下：

class oopDesc {
  friend class VMStructs; private: volatile markOop _mark; union _metadata { wideKlassOop _klass; narrowOop _compressed_klass; } _metadata; ... } 

其中的mark word即上述 _mark欄位，它在JVM中的表示型別是markOop, 部分關鍵原始碼如下所示，原始碼中展示了markWord各個欄位的意義及佔用大小(與機器字寬有關係)，如GC分代年齡、鎖狀態標記、雜湊碼、epoch、是否可偏向等資訊：

...
class markOopDesc: public oopDesc {
 private: // Conversion uintptr_t value() const { return (uintptr_t) this; } public: // Constants enum { age_bits = 4, lock_bits = 2, biased_lock_bits = 1, max_hash_bits = BitsPerWord - age_bits - lock_bits - biased_lock_bits, hash_bits = max_hash_bits > 31 ? 31 : max_hash_bits, cms_bits = LP64_ONLY(1) NOT_LP64(0), epoch_bits = 2 }; // The biased locking code currently requires that the age bits be // contiguous to the lock bits. enum { lock_shift = 0, biased_lock_shift = lock_bits, age_shift = lock_bits + biased_lock_bits, cms_shift = age_shift + age_bits, hash_shift = cms_shift + cms_bits, epoch_shift = hash_shift }; ... 

因為物件頭資訊只是物件執行時自身的一部分資料，相比例項資料部分，頭部分屬於與業務無關的額外儲存成功。為了提高物件對堆空間的複用效率，Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲儘量多的資訊，它會根據物件的狀態複用自己的儲存空間。

對於上述原始碼，mark word中欄位列舉意義解釋如下：

hash： 儲存物件的雜湊碼
age： 儲存物件的分代年齡
biased_lock： 偏向鎖標識位
lock： 鎖狀態標識位
JavaThread*： 儲存持有偏向鎖的執行緒ID
epoch： 儲存偏向時間戳

鎖標記列舉的意義解釋如下：

<pre style="box-sizing: border-box; overflow: auto; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; font-size: 13px; display: block; padding: 0px; margin: 0px; line-height: 1.42857; color: rgb(51, 51, 51); word-break: break-all; word-wrap: break-word; border: 1px solid rgb(204, 204, 204); border-radius: 4px;">locked_value = 0,//00 輕量級鎖
unlocked_value = 1,//01 無鎖
monitor_value = 2,//10 監視器鎖，也叫膨脹鎖，也叫重量級鎖
marked_value = 3,//11 GC標記
biased_lock_pattern = 5 //101 偏向鎖</pre>

實際上，markword的設計非常像網路協議報文頭：將mark word劃分為多個位元位區間，並在不同的物件狀態下賦予不同的含義, 下圖是來自網路上的一張協議圖。

  image.png

上述協議欄位正對應著原始碼中所列的列舉欄位，這裡簡要進行說明一下。

hash

物件的hash碼，hash代表的並不一定是物件的（虛擬）記憶體地址，但依賴於記憶體地址，具體取決於執行時庫和JVM的具體實現，底層由C++實現，實現細節參考OpenJDK原始碼。但可以簡單的理解為物件的記憶體地址的整型值。

age

物件分代GC的年齡。分代GC的年齡是指Java物件在分代垃圾回收模型下(現在JVM實現基本都使用的這種模型)，物件上標記的分代年齡，當該年輕代記憶體區域空間滿後，或者到達GC最達年齡時，會被扔進老年代等待老年代區域滿後被FullGC收集掉，這裡的最大年齡是通過JVM引數設定的：-XX:MaxTenuringThreshold ，預設值是15。那這個年齡具體是怎麼計算的呢？

下圖展示了該年齡遞增的過程：

1. 首先，在物件被new出來後，放在Eden區，年齡都是0

  image

2. 經過一輪GC後，B0和F0被回收，其它物件被拷貝到S1區，年齡增加1，注：如果S1不能同時容納A0,C0,D0,E0和G0，將被直接丟入Old區

  image

3. 再經一輪GC，Eden區中新生的物件M0,P0及S1中的B1,E1,G1不被引用將被回收，而H0,K0,N0及S1中的A1,D1被拷貝到S2區中，對應年齡增加1

  image

4. 如此經過2、3過濾迴圈進行，當S1或S2滿，或者物件的年齡達到最大年齡(15)後仍然有引用存在，則物件將被轉移至Old區。

鎖標記：lock/biased_lock/epoch/JavaThread*

鎖標記位，此鎖為重量級鎖，即物件監視器鎖。Java在使用synchronized關鍵字對方法或塊進行加鎖時，會觸發一個名為“objectMonitor”的監視器對目的碼塊執行加鎖的操作。當然synchronized方法和synchronized程式碼塊的底層處理機制稍有不同。synchronized方法編譯後，會被打上“ACC_SYNCHRONIZED”標記符。而synchronized程式碼塊編譯之後，會在同步程式碼的前後分別加上“monitorenter”和“monitorexit”的指令。當程式執行時遇到到monitorenter或ACC_SYNCHRONIZED時，會檢測物件頭上的lock標記位，該標記位被如果被執行緒初次成功訪問並設值，則置為1，表示取鎖成功，如果再次取鎖再執行++操作。在程式碼塊執行結束等待返回或遇到異常等待丟擲時，會執行monitorexit或相應的放鎖操作，鎖標記位執行--操作，如果減到0，則鎖被完全釋放掉。關於objectMonitor的實現細節，參考JDK原始碼

注意，在jdk1.6之前，synchronized加鎖或取鎖等待操作最終會被轉換為作業系統中執行緒操作原語，如啟用、阻塞等。這些操作會導致CPU執行緒上下文的切換，開銷較大，因此稱之為重量級鎖。但後續JDK版本中對其實現做了大幅優化，相繼出現了輕量級鎖，偏向鎖，自旋鎖，自適應自旋鎖，鎖粗化及鎖消除等策略。這裡僅做簡單介紹，不進行展開。

如圖所示，展示了這幾種鎖的關係：

  image

輕量級鎖，如上圖所示，是當某個資源在沒有競爭或極少競爭的情況下，JVM會優先使用CAS操作，讓執行緒在使用者態去嘗試修改物件頭上的鎖標記位，從而避免進入核心態。這裡CAS嘗試修改鎖標記是指嘗試對指向當前棧中儲存的lock record的執行緒指標的修改，即對biased_lock標記做CAS修改操作。如果發現存在多個執行緒競爭(表現為CAS多次失敗)，則膨脹為重量級鎖，修改對應的lock標記位並進入核心態執行鎖操作。注意，這種膨脹並非屬於效能的惡化，相反，如果競爭較多時，CAS方式的弊端就很明顯，因為它會佔用較長的CPU時間做無謂的操作。此時重量級鎖的優勢更明顯。

偏向鎖，是針對只會有一個執行緒執行同步程式碼塊時的優化，如果一個同步塊只會被一個執行緒訪問，則偏向鎖標記會記錄該執行緒id，當該執行緒進入時，只用check 執行緒id是否一致，而無須進行同步。鎖偏向後，會依據epoch(偏向時間戳)及設定的最大epoch判斷是否撤銷鎖偏向。

自旋鎖大意是指執行緒不進入阻塞等待，而只是做自旋等待前一個執行緒釋放鎖。不在物件頭討論範圍之列，這裡不做討論。

例項資料

例項資料instance Data是佔用堆記憶體的主要部分，它們都是物件的例項欄位。那麼計算這些欄位的大小，主要思路就是根據這些欄位的型別大小進行求和的。欄位型別的標準大小，如Java物件格式概述中表格描述的，除了引用型別會受CPU架構及是否開啟指標壓縮影響外，其它都是固定的。因此計算起來比較簡單。但實際情其實並不這麼簡單，例如如下物件：

class People{
   int age = 20; String name = "Xiaoming"; } class Person extends People{ boolean married = false; long birthday = 128902093242L; char tag = 'c'; double sallary = 1200.00d; } 

Person物件例項資料的大小應該是多少呢？這裡假設使用64位機器，採用指標壓縮，則物件頭的大小為：8(_mark)+4(_klass) = 12

然後例項資料的大小為： 4(age)+4(name) + 8(birthday) + 8(sallary) + 2(tag) + 1(married) = 27

因此最終的物件本身大小為：12+27+1(padding) = 40位元組

注意，為了儘量減少記憶體空間的佔用，這裡在計算的過程中需要遵循以下幾個規則：

> <pre style="box-sizing: border-box; overflow: auto; font-family: Menlo, Monaco, Consolas, &quot;Courier New&quot;, monospace; font-size: 13px; display: block; padding: 0px; margin: 0px; line-height: 1.42857; color: rgb(51, 51, 51); word-break: break-all; word-wrap: break-word; background-color: rgb(245, 245, 245); border: 1px solid rgb(204, 204, 204); border-radius: 4px;">/** > > * 1: 除了物件整體需要按8位元組對齊外，每個成員變數都儘量使本身的大小在記憶體中儘量對齊。比如 int 按 4 位對齊，long 按 8 位對齊。 > > * 2：類屬性按照如下優先順序進行排列：長整型和雙精度型別；整型和浮點型；字元和短整型；位元組型別和布林型別，最後是引用型別。這些屬性都按照各自的單位對齊。 > > * 3：優先按照規則一和二處理父類中的成員，接著才是子類的成員。 > > * 4：當父類中最後一個成員和子類第一個成員的間隔如果不夠4個位元組的話，就必須擴充套件到4個位元組的基本單位。 > > * 5：如果子類第一個成員是一個雙精度或者長整型，並且父類並沒有用完8個位元組，JVM會破壞規則2，按照整形（int），短整型（short），位元組型（byte），引用型別（reference）的順序，向未填滿的空間填充。 > > */</pre> 

最後計算引用型別欄位的實際大小："Xiaoming"，按字串物件的欄位進行計算，物件頭12位元組，hash欄位4位元組，char[] 4位元組，共12+4+4+4(padding) = 24位元組，其中char[]又是引用型別，且是陣列型別，其大小為：物件頭12+4(length) + 9(arrLength) * 2(char) +4(padding) = 40位元組。

所以綜上所述，一個Person物件佔用記憶體的大小為104位元組。

關於指標壓縮

一個比較明顯的問題是，在64位機器上，如果開啟了指標壓縮後，則引用只佔用4個位元組，4位元組的最大定址空間為2^32=4GB, 那麼如何保證能滿足定址空間大於4G的需求呢？

開啟指標壓縮後，實際上會壓縮的物件包括：每個Class的屬性指標(靜態成員變數)及每個引用型別的欄位(包括陣列)指標，而本地變數，堆疊元素，入參，返回值，NULL這些指標不會被壓縮。在開啟指標壓縮後，如前文原始碼所述，markWord中的儲存指標將是_compressed_klass，對應的型別是narrowOop，不再是wideKlassOop了，有什麼區別呢？

wideKlassOop和narrowOop都指向InstanceKlass物件，其中narrowOop指向的是經過壓縮的物件。簡單來說，wideKlassOop可以達到整個定址空間。而narrowOop雖然達不到整個定址空間，但它面對也不再是個單純的byte地址，而是一個object，也就是說使用narrowOop後，壓縮後的這4個位元組表示的4GB實際上是4G個物件的指標，大概是32GB。JVM會對對應的指標物件進行解碼, JDK原始碼中，oop.hpp原始碼檔案中定義了抽象的編解碼方法，用於將narrowOop解碼為一個正常的引用指標，或將一下正常的引用指標編碼為narrowOop：

  // Decode an oop pointer from a narrowOop if compressed.
  // These are overloaded for oop and narrowOop as are the other functions
  // below so that they can be called in template functions.
  static oop decode_heap_oop_not_null(oop v); static oop decode_heap_oop_not_null(narrowOop v); static oop decode_heap_oop(oop v); static oop decode_heap_oop(narrowOop v); // Encode an oop pointer to a narrow oop. The or_null versions accept // null oop pointer, others do not in order to eliminate the // null checking branches. static narrowOop encode_heap_oop_not_null(oop v); static narrowOop encode_heap_oop(oop v); 

對齊填充

對齊填充是底層CPU資料匯流排讀取記憶體資料時的要求，例如，通常CPU按照字單位讀取，如果一個完整的資料體不需要對齊，那麼在記憶體中儲存時，其地址有極大可能橫跨兩個字，例如某資料塊地址未對齊，儲存為1-4，而cpu按字讀取，需要把0-3字塊讀取出來，再把4-7字塊讀出來，最後合併捨棄掉多餘的部分。這種操作會很多很多，且很頻繁，但如果進行了對齊，則一次性即可取出目標資料，將會大大節省CPU資源。

在hotSpot虛擬機器中，預設的對齊位數是8，與CPU架構無關，如下程式碼中的objectAlignment：

// Try to get the object alignment (the default seems to be 8 on Hotspot, 
    // regardless of the architecture).
    int objectAlignment = 8;
    try { final Class<?> beanClazz = Class.forName("com.sun.management.HotSpotDiagnosticMXBean"); final Object hotSpotBean = ManagementFactory.newPlatformMXBeanProxy( ManagementFactory.getPlatformMBeanServer(), "com.sun.management:type=HotSpotDiagnostic", beanClazz ); final Method getVMOptionMethod = beanClazz.getMethod("getVMOption", String.class); final Object vmOption = getVMOptionMethod.invoke(hotSpotBean, "ObjectAlignmentInBytes"); objectAlignment = Integer.parseInt( vmOption.getClass().getMethod("getValue").invoke(vmOption).toString() ); supportedFeatures.add(JvmFeature.OBJECT_ALIGNMENT); } catch (Exception e) { // Ignore. } NUM_BYTES_OBJECT_ALIGNMENT = objectAlignment; 

可以看出，通過HotSpotDiagnosticMXBean.getVMOption("ObjectAlignmentBytes").getValue()方法可以拿到當前JVM環境下的對齊位數。

注意，這裡的HotSpotDiagnosticMXBean是JVM提供的JMX中一種可被管理的資源，即HotSpot資訊資源。

使用SA Hotspot Debuger(HSDB)檢視oops結構

前文所述都是原始碼+理論，其實Hotspot為我們提供了一種工具可以方便的用來查詢執行時物件的Oops結構，即SA Hotspot Debuger，簡稱HSDB. 其中SA指“Serviceability Agent”，它是一個JVM服務工具集的Agent，它原本是sun公司用來debug Hotspot的工具，現在開放給開發者使用，能夠檢視Java物件的oops、檢視類資訊、執行緒棧資訊、堆資訊、方法位元組碼和JIT編譯後的彙編程式碼等。SA提供的入口在$JAVA_HOME/lib/sa-jdi.jar中，包含了很多工具，其中最常用的工具就是HSDB。

下面演示一下HSDB的使用——

1. 先準備如下程式碼並執行：

public class Obj{
    private int age; private long height; private boolean married; private String name; private String addr; private String sex; ... get/set } 

package yp.tools;

/**
 * @author yepei
 * @date 2018/05/14
 * @description */ public class HSDBTest { public static void main(String[] args) throws InterruptedException { Obj o = new Obj(20, 175, false, "小明", "浙江杭洲", "男"); Thread.sleep(1000 * 3600); System.out.println(o); } } 

2. 執行jps命令，獲取當前執行的Java程序號：

  image

3. 啟動HSDB，並新增目標程序:

    `sudo java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.HSDB`

  image.png

可以看到當前Java程序中的執行緒資訊：

  image.png

雙擊指定執行緒，可以檢視到當前執行緒物件的Oop結構資訊，可以看到執行緒物件頭也是包含_mark和_metadata兩個協議欄位的：

  image.png

點選上方的棧圖示，可以查詢當前執行緒的棧記憶體：

  image.png

那麼如何檢視當前執行緒中使用者定義的類結儲存資訊呢？

先到方法區去看一下類資訊吧

Tools——Class Browser，搜尋目標類

  image.png

可以看到該類對應的物件的各個欄位的偏移量，最大的是36，String型別，意味著該物件本身的大小就是36+4 = 40位元組。同時，下方可以看到這個類相關的函式表、常量池資訊。

要檢視物件資訊，從Tools選單，開啟Object Histogram

  image.png

在開啟的視窗中搜索目標類：yp.tools.Obj

  image.png

雙擊開啟：

  image.png

點選Inspect檢視該物件的Oop結構資訊：

  image.png

如上圖所示即是物件Obj的Oop結構，物件頭包含_mark與代表class指標的_metadata。示例中的類沒有併發或鎖的存在，所以mark值是001，代表無鎖狀態。

除此之外，HSDB還有其它一些不錯的功能，如檢視反編譯資訊、根據地址查詢物件、crash分析、死鎖分析等。

總結

本文圍繞“計算Java物件佔用記憶體大小”這一話題，簡要介紹了直接計算指定物件在記憶體中大小的三種方法：使用Instrumentation、Unsafe或第三方工具(RamUsageEstimator)的方式，其中Instrumentation和Unsafe計算精確，但使用起來不太方便，Instrumentation需要以javaagent代理的方式啟動，而Unsafe只能計算指定物件的每個欄位的地址起始位置偏移量，需要手工遞歸併增加padding才能完整計算物件大小，使用RamUsageEstimator可以很方便的計算物件本身或物件引用樹整體的大小，但其並非直接基於物件的真實記憶體地址而計算的，而是通過已知JVM規則和資料型別的標準大小推算的，存在計算誤差的可能性。

為了揭開Java物件在堆記憶體中儲存格式的面紗，結合OpenJDK原始碼，本文著重討論了Java物件的格式：物件頭、例項資料及對齊填充三部分。其中物件頭最為複雜，包含_mark、_klass以及_length(僅陣列型別)的協議欄位。其中的mark word欄位較為複雜，甚至涉及了OOP-Klass模型、hash、gc、鎖的原理及指標壓縮等知識。

最後，從實踐的方面入手，介紹了JDK自帶的Hotspot Debuger工具——HSDB的使用，透過它能夠讓我們更直觀的檢視執行中的java物件在記憶體中的存在形式和狀態，如物件的oops、類資訊、執行緒棧資訊、堆資訊、方法位元組碼和JIT編譯後的彙編程式碼等。

本文查詢了一些資料，並參考了OpenJDK原始碼。可能會有些不正確的地方敬請指正，歡迎探討。

本文作者：一人淺醉

閱讀原文

本文為雲棲社群原創內容，未經允許不得轉載。

作者：阿里云云棲社群
連結：https://www.jianshu.com/p/9d729c9c94c4
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。