如何計算Java對象所佔內存的大小

時間  2019-11-15
標籤 如何 計算 java 對象 所佔 內存 大小 欄目 Java 简体版
原文   原文鏈接

摘要

本文以如何計算Java對象佔用內存大小爲切入點，在討論計算Java對象佔用堆內存大小的方法的基礎上，詳細討論了Java對象頭格式並結合JDK源碼對對象頭中的協議字段作了介紹，涉及內存模型、鎖原理、分代GC、OOP-Klass模型等內容。最後推薦JDK自帶的Hotspot Debug工具——HSDB，來查看對象在內存中的具體存在形式，以論證文中所述內容。
背景
目前咱們系統的業務代碼中大量使用了LocalCache的方式作本地緩存，並且cache的maxSize一般設的比較大，好比10000。咱們的業務系統中就使用了size爲10000的15個本地緩存，因此最壞狀況下將可緩存15萬個對象。這會消耗掉不菲的本地堆內存，而至於實際上到底應該設多大容量的緩存、運行時這大量的本地緩存會給堆內存帶來多少壓力，實際佔用多少內存大小，會不會有較高的緩存穿透風險，目前並不方便知悉。考慮到對緩存實際佔用內存的大小能有個更直觀和量化的參考，須要對運行時指定對象的內存佔用進行評估和計算。java

要計算Java對象佔用內存的大小，首先須要瞭解Java對象在內存中的實際存儲方式和存儲格式。c++

另外一方面，你們都瞭解Java對象的存儲總得來講會佔用JVM內存的堆內存、棧內存及方法區，但因爲棧內存中存放的數據能夠看作是運行時的臨時數據，主要表現爲本地變量、操做數、對象引用地址等。這些數據會在方法執行結束後當即回收掉，不會駐留。對存儲空間空間的佔用也只是執行函數指令時所必須的空間。一般不會形成內存的瓶頸。而方法區中存儲的則是對象所對應的類信息、函數表、構造函數、靜態常量等，這些信息在類加載時(按需)只會在方法區中存儲一份，不會產生額外的存儲空間。所以本文所要討論的主要目標是Java對象對堆內存的佔用。git

內存佔用計算方法

若是讀者關心對象在JVM中的存儲原理，可閱讀本文後邊幾個小節中關於對象存儲原理的介紹。若是不關心對象存儲原理，而只想直接計算內存佔用的話，其實並不難，筆者這裏總結了三種方法以供參考：github

1. Instrumentation
使用java.lang.instrument.Instrumentation.getObjectSize()方法，能夠很方便的計算任何一個運行時對象的大小，返回該對象自己及其間接引用的對象在內存中的大小。不過，這個類的惟一實現類InstrumentationImpl的構造方法是私有的，在建立時，須要依賴一個nativeAgent，和運行環境所支持的一些預約義類信息，咱們在代碼中沒法直接實例化它，須要在JVM啓動時，經過指定代理的方式，讓JVM來實例化它。apache

具體來說，就是須要聲明一個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對象結構大體以下圖所示——

clipboard.png

即，Java對象從總體上能夠分爲三個部分，對象頭、實例數據和對齊填充

對象頭：Instance Header，Java對象最複雜的一部分，採用C++定義了頭的協議格式，存儲了Java對象hash、GC年齡、鎖標記、class指針、數組長度等信息，稍後作出詳細解說。

實例數據：Instance Data，這部分數據纔是真正具備業務意義的數據，實際上就是當前對象中的實例字段。在VM中，對象的字段是由基本數據類型和引用類型組成的。其所佔用空間的大小以下所示：

類型 大小(字節) 類型 大小(字節)
byte 1 int 4
boolean 1 float 4
char 2 long 8
short 2 double 8
ref 4(32bit) OR 8(64bit) OR 4(64bit && -XX:UseCompressedOops)

說明：其中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源碼能夠看到，有不少模型定義的名稱都是以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-mi...；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對象的表示關係以下所示：

clipboard.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： 保存偏向時間戳

鎖標記枚舉的意義解釋以下：

locked_value = 0,//00 輕量級鎖
unlocked_value = 1,//01 無鎖
monitor_value = 2,//10 監視器鎖，也叫膨脹鎖，也叫重量級鎖
marked_value = 3,//11 GC標記
biased_lock_pattern = 5 //101 偏向鎖
實際上，markword的設計很是像網絡協議報文頭：將mark word劃分爲多個比特位區間，並在不一樣的對象狀態下賦予不一樣的含義, 下圖是來自網絡上的一張協議圖。

clipboard.png

上述協議字段正對應着源碼中所列的枚舉字段，這裏簡要進行說明一下。

hash
對象的hash碼，hash表明的並不必定是對象的（虛擬）內存地址，但依賴於內存地址，具體取決於運行時庫和JVM的具體實現，底層由C++實現，實現細節參考OpenJDK源碼。但能夠簡單的理解爲對象的內存地址的整型值。

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

下圖展現了該年齡遞增的過程：
  1. 首先，在對象被new出來後，放在Eden區，年齡都是0

clipboard.png

  1. 通過一輪GC後，B0和F0被回收，其它對象被拷貝到S1區，年齡增長1，注：若是S1不能同時容納A0,C0,D0,E0和G0，將被直接丟入Old區

clipboard.png

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

clipboard.png

  1. 如此通過二、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版本中對其實現作了大幅優化，相繼出現了輕量級鎖，偏向鎖，自旋鎖，自適應自旋鎖，鎖粗化及鎖消除等策略。這裏僅作簡單介紹，不進行展開。

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

clipboard.png

輕量級鎖，如上圖所示，是當某個資源在沒有競爭或極少競爭的狀況下，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字節

注意，爲了儘可能減小內存空間的佔用，這裏在計算的過程當中須要遵循如下幾個規則：

/**

* 1: 除了對象總體須要按8字節對齊外，每一個成員變量都儘可能使自己的大小在內存中儘可能對齊。好比 int 按 4 位對齊，long 按 8 位對齊。

* 2：類屬性按照以下優先級進行排列：長整型和雙精度類型；整型和浮點型；字符和短整型；字節類型和布爾類型，最後是引用類型。這些屬性都按照各自的單位對齊。

* 3：優先按照規則一和二處理父類中的成員，接着纔是子類的成員。

* 4：當父類中最後一個成員和子類第一個成員的間隔若是不夠4個字節的話，就必須擴展到4個字節的基本單位。

* 5：若是子類第一個成員是一個雙精度或者長整型，而且父類並無用完8個字節，JVM會破壞規則2，按照整形（int），短整型（short），字節型（byte），引用類型（reference）的順序，向未填滿的空間填充。

*/

最後計算引用類型字段的實際大小："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);
    }
}
  1. 執行jps命令，獲取當前運行的Java進程號：

clipboard.png

  1. 啓動HSDB，並添加目標進程:

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

clipboard.png

能夠看到當前Java進程中的線程信息：

clipboard.png

雙擊指定線程，能夠查看到當前線程對象的Oop結構信息，能夠看到線程對象頭也是包含_mark和_metadata兩個協議字段的：

clipboard.png

點擊上方的棧圖標，能夠查詢當前線程的棧內存：

clipboard.png

那麼如何查看當前線程中用戶定義的類結存儲信息呢？

先到方法區去看一下類信息吧

Tools——Class Browser，搜索目標類

clipboard.png

能夠看到該類對應的對象的各個字段的偏移量，最大的是36，String類型，意味着該對象自己的大小就是36+4 = 40字節。同時，下方能夠看到這個類相關的函數表、常量池信息。

要查看對象信息，從Tools菜單，打開Object Histogram

clipboard.png

在打開的窗口中搜索目標類：yp.tools.Obj

clipboard.png

雙擊打開：

clipboard.png

點擊Inspect查看該對象的Oop結構信息：

clipboard.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源碼。可能會有些不正確的地方敬請指正，歡迎探討。

本文做者：一人淺醉

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程