摘要

本文以如何計算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)//計算指定對象及其引用樹上的所有對象的綜合大小，返回可讀的結果，如：2KBString 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:// Conversionuintptr_t value() const { return (uintptr_t) this; }public:// Constantsenum { 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; background-color: rgb(245, 245, 245); 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
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權并注明出處。

總結

以上是生活随笔為你收集整理的如何计算Java对象所占内存的大小的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。