一、先上答案

这个问题有坑，有两种回答

第一种解释：

object实例对象，占16个字节。

第二种解释：

Object o：普通对象指针（ordinary object pointer），占4个字节。
new Object()：object实例对象，占16个字节。
所以一共占：4+16=20个字节。

第二种解释就是在玩文字游戏了，但还是要知道的。

二、这个答案适用于所有情况吗

并不是，这个答案只适用于现在一般默认情况。

准确的说，只适用于HotSpot实现的64位虚拟机，默认开启了压缩类指针和压缩普通对象指针的情况下。

本文下述内容若无特殊说明，指的都是JDK8 HotSpot实现的64位虚拟机的未开启压缩的情况。

三、前置知识

在 JVM 中，Java对象保存在堆中时，由以下三部分组成：

• 对象头（Object Header）：包括关于堆对象的布局、类型、GC状态、同步状态和标识哈希码的基本信息。由两个词mark word和klass pointer组成，如果是数组对象的话，还会有一个length field。
  • mark word：通常是一组位域，用于存储对象自身的运行时数据，如hashCode、GC分代年龄、锁同步信息等等。占用64个比特，8个字节。
  • klass pointer：类指针，是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。占用64个比特，8个字节。开启压缩类指针后，占用32个比特，4个字节。
• 实例数据（Instance Data）：存储了代码中定义的各种字段的内容，包括从父类继承下来的字段和子类中定义的字段。如果对象无属性字段，则这里就不会有数据。根据字段类型的不同占不同的字节，例如boolean类型占1个字节，int类型占4个字节等等。为了提高存储空间的利用率，这部分数据的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。
• 对齐填充（Padding）：对象可以有对齐数据也可以没有。默认情况下，Java虚拟机堆中对象的起始地址需要对齐至8的整数倍。如果一个对象的对象头和实例数据占用的总大小不到8字节的整数倍，则以此来填充对象大小至8字节的整数倍。

为什么要对齐填充？字段内存对齐的其中一个原因，是让字段只出现在同一CPU的缓存行中。如果字段不是对齐的，那么就有可能出现跨缓存行的字段。也就是说，该字段的读取可能需要替换两个缓存行，而该字段的存储也会同时污染两个缓存行。这两种情况对程序的执行效率而言都是不利的。其实对其填充的最终目的是为了计算机高效寻址。

我看到网络上有些文章把mark word称之为对象头，把java对象的内存布局分为4个部分mark word、klass pointer、instance data、padding，这很明显是没有看过官方文档的，说法并不严谨。关于对象头，可以在HotSpot官方文档找到下面的描述：

四、详细解释

因为第二种解释包含了第一种解释，所以我们分析第二种解释。

1.Object o

在HotSpot实现的64位虚拟机中，原本情况下，它内部的一个引用，就应该占64个比特，也就是8个字节。什么叫引用啊？上面那个变量小o，就叫引用，也叫普通对象指针（别说什么java里没有指针，什么引用和指针不一样。我不想去争论这个）。但是，在第二种解释中我们说了，普通对象指针，占4个字节，怎么又成8个字节了，怎么回事呢？

这是因为HotSpot实现的64位虚拟机，默认会开启压缩普通对象指针，会把8个字节的对象引用，压缩成4个字节。

Object o占用大小分为两种情况：

• 未开启压缩对象指针

  8字节

• 开启压缩对象指针（默认是开启的）

  4字节

2.new Object()

同样的，在HotSpot实现的64位虚拟机中，原本情况下，类指针应该占64个比特，也就是8个字节。但因为HotSpot实现的64位虚拟机，默认会开启压缩类指针（和压缩对象指针不一样），而类指针就在Klass Pointer中存储着，所以会把Klass Pointer压缩成4个字节。

new Object()占用大小分为两种情况：

• 未开启压缩类指针

  8字节(Mark Word) + 8字节(Klass Pointer) = 16字节

• 开启压缩类指针（默认是开启的）

  8字节(Mark Word) + 4字节(Klass Pointer) + 4字节(Padding) = 16字节

五、验证

光说不练假把式，实践出真知，上面的只是理论，我们来实际验证下，是不是真的是这样。

1.验证默认开启压缩

首先，我们来看下，JDK8 HotSpot实现的64位虚拟机，是不是会默认开启压缩类指针和压缩普通对象指针。

win + R，输入cmd，敲入下面的命令java -version，相信大家对这个命令很熟悉了，查看java版本

接下来我们加个参数-XX:+PrintCommandLineFlags，这个参数让JVM打印出那些已经被用户或者JVM设置过的详细的XX参数的名称和值，注意看下面两个参数

-XX:+UseCompressedClassPointers：使用压缩类指针

-XX:+UseCompressedOops：使用压缩普通对象指针

可以看到，这两个配置是默认开启的。

注意：32位HotSpot VM是不支持UseCompressedOops参数的，只有64位HotSpot VM才支持。

什么是oop？

这参数后面的oop可不是面向对象编程Object Oriented Programming的意思，而是普通对象指针Ordinary Object Pointer。

启用UseCompressedOops后，会压缩的对象：

• 每个Class的属性指针（静态成员变量）；
• 每个对象的属性指针；
• 普通对象数组的每个元素指针。

当然，压缩也不是所有的指针都会压缩，对一些特殊类型的指针，JVM是不会优化的，例如指向PermGen的Class对象指针、本地变量、堆栈元素、入参、返回值和NULL指针不会被压缩。

关于UseCompressedClassPointers和UseCompressedOops

这样一看，好像UseCompressedOops对Object的内存布局并没有影响，其实不然，开启UseCompressedOops，默认会开启UseCompressedClassPointers，会压缩klass pointer这部分的大小，由8字节压缩至4字节，间接的提高内存的利用率。关闭UseCompressedOops默认会关闭UseCompressedClassPointers。

如果开启类指针压缩，+UseCompressedClassPointers，并关闭普通对象指针压缩，-UseCompressedOops，此时会报警告，"Java HotSpot(TM) 64-Bit Server VM warning: UseCompressedClassPointers requires UseCompressedOops"。因为UseCompressedClassPointers的开启是依赖于UseCompressedOops的开启。

总结下就是，开了UseCompressedOops，UseCompressedClassPointers可开可不开，默认会也被打开。关了UseCompressedOops，UseCompressedClassPointers开了会报警告，默认会也被关掉。这两个配置，在不特意修改的情况下都是默认开启的。

2.验证实例对象布局大小

上面已经看到，JVM默认开启了压缩类指针和压缩普通对象指针，那么在这个情况下，new Object()是否真的是8字节(Mark Word) + 4字节(Klass Pointer) + 4字节(Padding) = 16字节呢？

还好 openjdk 给我们提供了一个工具包，可以用来获取对象的信息和虚拟机的信息，我们只需引入 jol-core 依赖，如下：

	org.openjdk.jol
	jol-core
	0.14

jol-core 常用的三个方法：

• ClassLayout.parseInstance(object).toPrintable()：查看对象内部信息.
• GraphLayout.parseInstance(object).toPrintable()：查看对象外部信息，包括引用的对象.
• GraphLayout.parseInstance(object).totalSize()：查看对象总大小.

简单对象

为了简单化，我们不用复杂的对象，自己创建一个类 Test01，先看无属性字段的时候

public class Test01 {

    public static void main(String[] args) {
        Test01 t = new Test01();
        System.out.println(ClassLayout.parseInstance(t).toPrintable());
    }

}

通过 jol-core 的 api，我们将对象的内部信息打印出来：

可以看到有 OFFSET、SIZE、TYPE DESCRIPTION、VALUE 这几个名词头，它们的含义分别是

• OFFSET：偏移地址，单位字节；
• SIZE：占用的内存大小，单位为字节；
• TYPE DESCRIPTION：类型描述，其中object header为对象头；
• VALUE：对应内存中当前存储的值，二进制32位；

同时可以看到，t实例对象共占据16Byte，object header占据12Byte，其中mark word占8Byte，klass pointer占4Byte，还有padding占4Byte。

如果我把压缩类指针的参数去掉呢？可以通过配置vm参数关闭压缩类指针，-XX:-UseCompressedClassPointers。我们再看看结果：

可以看到，t实例对象还是占据16Byte，但object header所占用的内存大小变为16Byte，其中mark word占8Byte，klass pointer占8Byte，无padding。

klass pointer的大小从上面的4Byte，变成了8Byte，正是因为没有对它进行压缩。同时也因为对象大小已经达到16Byte，是8的整数倍，所以不再需要padding。

至此，已经证明了我们上面的结论是正确的。

有成员变量的对象

我们现在给Test01类里加4个成员变量，开启两个指针压缩，再看看它的布局吧

public class Test01 {

    String a = "a";

    int b = 1;

    boolean c = false;

    char d = 'd';

    public static void main(String[] args) {
        Test01 t = new Test01();
        System.out.println(ClassLayout.parseInstance(t).toPrintable());
    }

}

可以看到，对象大小变成了24Byte，其中mark word占8Byte，klass pointer占4Byte，int占4Byte，char占2Byte，boolean占1Byte，padding占1Byte，String类型的变量a占4Byte，也验证了我们上面说的“为了提高存储空间的利用率，这部分数据的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响”，可以看到内存中的布局顺序确实和我们定义的不一样。

此时我再关闭两个指针压缩，再看看布局变化：

可以看到，对象总大小变成了32Byte，和开启压缩类指针相比，klass pointer大了4Byte，和开启压缩普通对象指针相比，String类型的变量a大了4Byte。符合我们上面的结论。