java_计算内存对象大小

导语：现在公司的代码评审越来越严格，技术方案评审上经常会问到对象设计的合理性，对于常驻内存的对象，我们应在设计时考虑到对象占用的内存空间，保证JVM运行时不会频繁GC，确保系统的稳定性和可靠性。

参考文章 https://segmentfault.com/a/1190000015009289

Java对象介绍

Java对象从整体分为三部分：对象头，实例数据，对齐填充数据；

保存在堆上：实例数据，对象头的mark属性；

保存在"方法区"：类的元数据；

保存在栈上：对象的引用；

对象头

采用C++定义了头的协议格式，存储了Java对象hash、GC年龄、锁标记、class指针、数组长度等信息；

• 普通对象(32位)

  |--------------------------------------------------------------|
  |                    Object Header (8byte->64 bits)            |
  |------------------------------------|-------------------------|
  |          Mark Word (32 bits)       |   Klass Word (32 bits)  |
  |------------------------------------|-------------------------|
  

• 数组对象(32位)

  比普通对象多了4个字节的长度标记

  |---------------------------------------------------------------------------------|
  |                     Object Header (8+4=12byte->96 bits)                         |
  |--------------------------------|-----------------------|------------------------|
  |         Mark Word(32bits)      |  Klass Word(32bits)   |   array length(32bits) |
  |--------------------------------|-----------------------|------------------------|
  

mark字段：描述了对象的Hash值，锁记录，锁类型等对象运行时自身的一部分数据；(可参考之前锁介绍的文章)；该内容保存在堆中；

klass字段：他是一个指向方法区(在java8中移除了永久代的内容，方法区由**元空间(Meta Space)**实现)的指针，方法区中会开辟一块内存用于保存class信息，例如我们的方法表等之类的可以参考之前写的深入理解JVM第六章；

• 对象头的实际大小
  1. 在32位系统下，存放Class指针的空间大小是4字节，MarkWord是4字节，对象头为8字节。
  2. 在64位系统下，存放Class指针的空间大小是8字节，MarkWord是8字节，对象头为16字节。
  3. 在64位开启指针压缩的情况下 -XX:+UseCompressedOops，存放Class指针的空间大小是4字节，MarkWord是8字节，对象头为12字节。
  4. 如果对象是数组，那么额外增加4个字节。

实例数据

实例数据是占用堆内存的主要部分，它们都是对象的实例字段；

内存对齐

在hotSpot虚拟机中，默认的对齐位数是8，与CPU架构无关;

1. 除了对象整体需要按8字节对齐外，每个成员类型都尽量使本身的大小在内存中尽量对齐。比如 int 按 4 对齐，long 按 8 对齐；

   如果有boolean和String两个字段，其中boolean是38位，则String必须保证4对其，应从40开始；

   如果有byte，byte和String三个字段，其中byte是38位，则下一个byte保证1对其，则为39，String是从40开始；

2. 类属性按照如下优先级进行排列：长整型和双精度类型；整型和浮点型；字符和短整型；字节类型和布尔类型，最后是引用类型。这些属性都按照各自的单位对齐。

   这块特殊说明一下，不开指针压缩下是按照上述顺序进行排序的；

   当开启指针压缩时，对象头占12个字节，这时JVM需要优先找小于等于4字节的对象进行内存对其，当补齐到16字节后，仍按照上序顺序排序；

   例：一个对象有 byte1,byte2,byte3,byte4,byte5,double1,byte6;

   重排序结果为:byte1,byte2,byte3,byte4,double1,byte5,byte6;

3. 优先按照规则1和2处理父类中的成员，接着才是子类的成员。

4. 当父类中最后一个成员和子类第一个成员的间隔如果不够4个字节的话，就必须扩展到4个字节的基本单位。

5. 如果子类第一个成员是一个双精度或者长整型，并且父类并没有用完8个字节，JVM会破坏(规则2)，按照整形（int），短整型（short），字节型（byte），引用类型（reference）的顺序，向未填满的空间填充。

内存大小计算

以64位，开启指针压缩计算

// 水果
class Fruit {
    // 字节
    byte _byte; // 1
    // 描述
    String desc; // 引用4byte
    // 是否成熟
    boolean isMature;// 1
    // 价格
    double price; // 8
    // 产地标记
    char location; // 2
    // 时间戳
    long timestamp; // 8
    // 对象状态
    int state; // 4
    // 浮点数
    float _float; //4
}

手工计算

对象头+根据规则2的重排序+8字节对其；

使用Unsafe工具类

Unsafe是单纯计算所占用的大小，而不是计算实例化对象所占用的实际大小；可用作预估计算；

我们使用Unsafe工具类，去获取每个对象的起始偏移量；我们发现，字段出现了重排序，符合内存对其规则2所述的字段排序；

public static void test() throws Exception{
    Field theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe");
    theUnsafeField.setAccessible(true);
    Unsafe unsafe = (Unsafe) theUnsafeField.get(null);

    // 起始38 占用1
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("_byte")));
    // 起始40 占用4
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("desc")));
    // 起始39 占用1
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("isMature")));
    // 起始16 占用8
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("price")));
    // 起始36 占用2
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("location")));
    // 起始24 占用8
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("timestamp")));
    // 起始12 占用4 （因为对象头占12字节，所以实例数据起始位置是12）
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("state")));
    // 起始32 占用4
    System.out.println(unsafe.objectFieldOffset(Fruit.class.getDeclaredField("_float")));
}

我们计算Fruit大小：对象头(12)+实例数据大小共44，对象整体保证8字节对齐，则该对象大小(不包含引用对象String)为48字节;

使用lucene-core计算

他是生成一个实例对象，然后计算真实占用内存的大小；

<!-- 引入jar包 -->
<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-core</artifactId>
    <version>4.0.0</version>
</dependency>

public static void main() {
    // 实例化了一个对象
    Fruit p = new Fruit();
    // 计算指定对象及其引用树上的所有对象的综合大小，单位字节
    // 就是真实占用的大小
    System.out.println(RamUsageEstimator.sizeOf(p)); // 48
    // 计算指定对象本身在堆空间的大小，单位字节
    // 就是我们用unsafe计算的逻辑计算出来的大小
    System.out.println(RamUsageEstimator.shallowSizeOf(p));// 48
    // 计算指定对象及其引用树上的所有对象的综合大小，返回可读的结果
    // 就是第一个方法的结果带上单位
    System.out.println(RamUsageEstimator.humanSizeOf(p)); // 48 bytes
}

上面用lucene-core计算出来堆内存和包含引用树对象的大小是一致的，但当我们给实例对象的引用赋值后，大小就不一致了，我们看下下面的例子；

public static void main3() {
    Fruit p = new Fruit();
    p.desc = "这是个水果";
    System.out.println(RamUsageEstimator.sizeOf(p)); // 104
    System.out.println(RamUsageEstimator.shallowSizeOf(p));// 48
    System.out.println(RamUsageEstimator.humanSizeOf(p));// 104 bytes
    System.out.println(RamUsageEstimator.humanSizeOf(p));
}

我们可以看到，当给引用对象赋值后，堆空间没有变化，但对象真实大小发生变化；是因为引用对象开辟了空间，我们的真实大小包含堆空间占用+引用对象的占用；这里String对象被赋值后，就开启了新的内存空间，其中String对象又包含了char[]数组；所以真实对象占用空间会大于堆空间占用；