深入理解 Java 对象结构

一、Java 对象结构

实例化一个 Java 对象之后，该对象在内存中的结构是怎么样的？Java 对象（Object 实例）结构包括三部分：对象头、对象体和对齐字节，具体下图所示

1、Java 对象的三部分

（1）对象头

对象头包括三个字段，第一个字段叫作 Mark Word（标记字），用于存储自身运行时的数据，例如 GC 标志位、哈希码、锁状态等信息。

第二个字段叫作 Class Pointer（类对象指针），用于存放方法区 Class 对象的地址，虚拟机通过这个指针来确定这个对象是哪个类的实例。

第三个字段叫作 Array Length（数组长度）。如果对象是一个 Java 数组，那么此字段必须有，用于记录数组长度的数据；如果对象不是一个 Java 数组，那么此字段不存在，所以这是一个可选字段。

（2）对象体

对象体包含对象的实例变量（成员变量），用于成员属性值，包括父类的成员属性值。这部分内存按 4 字节对齐。

（3）对齐字节

对齐字节也叫作填充对齐，其作用是用来保证 Java 对象所占内存字节数为 8 的倍数 HotSpot VM 的内存管理要求对象起始地址必须是 8 字节的整数倍。对象头本身是 8 的倍数，当对象的实例变量数据不是 8 的倍数时，便需要填充数据来保证 8 字节的对齐。

2、Mark Word 的结构信息

Mark Word 是对象头中的第一部分，Java 内置锁有很多重要的信息都存在这里。Mark Word 的位长度为 JVM 的一个 Word 大小，也就是说 32 位 JVM 的 Mark Word 为 32 位，64 位 JVM 为 64 位。Mark Word 的位长度不会受到 Oop 对象指针压缩选项的影响。

Java 内置锁的状态总共有 4 种，级别由低到高依次为：无锁、偏向锁、轻量级锁和重量级锁。其实在 JDK 1.6 之前，Java 内置锁还是一个重量级锁，是一个效率比较低下的锁，在 JDK 1.6 之后，JVM 为了提高锁的获取与释放效率，对 synchronized 的实现进行了优化，引入了偏向锁和轻量级锁，从此以后 Java 内置锁的状态就有了 4 种（无锁、偏向锁、轻量级锁和重量级锁），并且 4 种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，也就是说只能进行锁升级（从低级别到高级别）。以下是 64 位的 Mark Word 在不同的锁状态下的结构信息：

由于目前主流的 JVM 都是 64 位，因此我们使用 64 位的 Mark Word。接下来对 64 位的 Mark Word 中各部分的内容进行具体介绍。

（1）lock：锁状态标记位，占两个二进制位，由于希望用尽可能少的二进制位表示尽可能多的信息，因此设置了 lock 标记。该标记的值不同，整个 Mark Word 表示的含义就不同。

（2）biased_lock：对象是否启用偏向锁标记，只占 1 个二进制位。为 1 时表示对象启用偏向锁，为 0 时表示对象没有偏向锁。

lock 和 biased_lock 两个标记位组合在一起共同表示 Object 实例处于什么样的锁状态。二者组合的含义具体如下表所示

（3）age：4 位的 Java 对象分代年龄。在 GC 中，对象在 Survivor 区复制一次，年龄就增加 1。当对象达到设定的阈值时，将会晋升到老年代。默认情况下，并行 GC 的年龄阈值为 15，并发 GC 的年龄阈值为 6。由于 age 只有 4 位，因此最大值为 15，这就是-XX:MaxTenuringThreshold 选项最大值为 15 的原因。

（4）identity_hashcode：31 位的对象标识 HashCode（哈希码）采用延迟加载技术，当调用 Object.hashCode()方法或者 System.identityHashCode()方法计算对象的 HashCode 后，其结果将被写到该对象头中。当对象被锁定时，该值会移动到 Monitor（监视器）中。

（5）thread：54 位的线程 ID 值为持有偏向锁的线程 ID。

（6）epoch：偏向时间戳。

（7）ptr_to_lock_record：占 62 位，在轻量级锁的状态下指向栈帧中锁记录的指针。

二、使用 JOL 工具查看对象的布局

1、JOL 工具的使用

JOL 工具是一个 jar 包，使用它提供的工具类可以轻松解析出运行时 java 对象在内存中的结构，使用时首先需要引入 maven GAV 信息

<!--Java Object Layout --><dependency>    <groupId>org.openjdk.jol</groupId>    <artifactId>jol-core</artifactId>    <version>0.17</version></dependency>

当前最新版本是 0.17 版本，据观察，它和 0.15 之前（不包含 0.15）的版本输出信息差异比较大，而普遍现在使用的版本都比较低，但是不妨碍在这里使用该工具做实验。

jol-core 常用的几个方法

• ClassLayout.parseInstance(object).toPrintable()：查看对象内部信息.

• GraphLayout.parseInstance(object).toPrintable()：查看对象外部信息，包括引用的对象.

• GraphLayout.parseInstance(object).totalSize()：查看对象总大小.

• VM.current().details()：输出当前虚拟机信息

首先创建一个简单的类 Hello

public class Hello {    private Integer a = 1;   }

接下来写一个启动类测试下

import lombok.extern.slf4j.Slf4j;import org.openjdk.jol.info.ClassLayout;import org.openjdk.jol.vm.VM;
/** * @author kdyzm * @date 2024/9/19 */@Slf4jpublic class JalTest {
    public static void main(String[] args) {        log.info(VM.current().details());        Hello hello = new Hello();        log.info("hello obj status:{}", ClassLayout.parseInstance(hello).toPrintable());    }}

输出结果：

2、结果分析

在代码中，首先使用了VM.current().details() 方法获取到了当前 java 虚拟机的相关信息：

• VM mode: 64 bits - 表示当前虚拟机是 64 位虚拟机

• Compressed references (oops): 3-bit shift - 开启了对象指针压缩，在 64 位的 Java 虚拟机上，对象指针通常需要占用 8 字节（64 位），但通过使用压缩指针技术，可以减少对象指针的占用空间，提高内存利用率。"3-bit shift" 意味着使用 3 位的位移操作来对对象指针进行压缩。通过将对象指针右移 3 位，可以消除指针中的一些无用位，从而减少对象指针的实际大小，使其占用更少的内存。

• Compressed class pointers: 3-bit shift - 开启了类指针压缩，其余同上。

• Object alignment: 8 bytes - 字节对齐使用 8 字节

这部分输出表示引用类型、boolean、byte、char、short、int、float、long、double 类型的数据所占的字节数大小以及在数组中的大小和偏移量。

需要注意的是数组偏移量的概念，数组偏移量的数值其实就是对象头的大小，在上图中的 16 字节表示如果当前对象是数组，那对象头就是 16 字节，不要忘了，对象头中还有数组长度，在未开启对象指针压缩的情况下，它要占据 4 字节大小。

接下来是对象结构的输出分析。

三、对象结构输出解析

先回顾下对象结构

再来回顾下对象结构输出结果

• OFF：偏移量，单位字节

• SZ：大小，单位字节

• TYPE DESCRIPTION：类型描述，这里显示的比较直观，甚至可以看到是对象头的哪一部分

• VALUE：值，使用十六进制字符串表示，注意一个字节是 8bit，占据两个 16 进制字符串，JOL0.15 版本之前是小端序展示，0.15（包含 0.15）版本之后使用大端序展示。

  1、Mark Word 解析

因为当前虚拟机是 64 位的虚拟机，所以 Mark Word 在对象头中占据 8 字节，也就是 64 位。它不受指针压缩的影响，占据内存大小只和当前虚拟机有关系。

当前的值是十六进制数值：0x0000000000000001，为了好看点，将它按照字节分割开：00 00 00 00 00 00 00 01，然后，来回顾下 mark workd 的内存结构：

最后一个字节是十六进制的 01，转化为二进制数，就是00000001，那倒数三个 bit 就是001，偏向锁标志位 biased 是 0，lock 标志位是 01，对应的是无锁状态下的 mark word 数据结构。

2、Class Pointer 解析

该字段在 64 位虚拟机下开启指针压缩占据 4 字节，未开启指针压缩占据 8 字节，它指向方法区的内存地址，即 Class 对象所在的位置。

3、对象体解析

Hello 类只有一个 Integer 类型的变量 a，它在 64 位虚拟机下开启指针压缩占据 4 字节，未开启指针压缩占据 8 字节大小。需要注意的是，这里的 8 字节存储的是 Integer 对象指针大小，而非 int 类型的数值所占内存大小。

四、不同条件下的对象结构变化

1、Mark Word 中的 hashCode

在无锁状态下，对象头中的 mark word 字段有 31bit 是用于存放 hashCode 的值的，但是在之前的打印输出中，hashCode 全是 0，这是为什么？

想要 hashCode 的值能够在 mark word 中展示，需要满足两个条件：

1. 目标类不能重写 hashCode 方法

2. 目标对象需要调用 hashCode 方法生成 hashCode

上面的实验中，Hello 类很简单

public class Hello {    private Integer a = 1;   }

没有重写 hashCode 方法，使用 JOL 工具分析没有看到 hashCode 值，是因为没有调用 hashCode()方法生成 hashCode 值

接下来改下启动类，调用下 hashCode 方法，重新输出解析结果

import lombok.extern.slf4j.Slf4j;import org.openjdk.jol.info.ClassLayout;import org.openjdk.jol.vm.VM;
/** * @author kdyzm * @date 2024/9/19 */@Slf4jpublic class JalTest {
    public static void main(String[] args) {        log.info(VM.current().details());        Hello hello = new Hello();        hello.hashCode();        log.info("hello obj status:{}", ClassLayout.parseInstance(hello).toPrintable());    }}

输出结果

可以看到，Mark Word 中已经有了 hashCode 的值。

2、字节对齐

从 JOL 输出上来看，使用的是 8 字节对齐，而对象正好是 16 字节，是 8 的整数倍，所以并没有使用字节对齐，为了能看到字节对齐的效果，再给 Hello 类新增一个成员变量Integer b = 2，已知一个整型变量在这里占用 4 字节大小空间，对象大小会变成 20 字节，那就不是 8 的整数倍，会有 4 字节的对齐字节填充，改下 Hello 类

public class Hello {    private Integer a = 1;    private Integer b = 2;}

然后运行启动类

import lombok.extern.slf4j.Slf4j;import org.openjdk.jol.info.ClassLayout;import org.openjdk.jol.vm.VM;
/** * @author kdyzm * @date 2024/9/19 */@Slf4jpublic class JalTest {
    public static void main(String[] args) {        log.info(VM.current().details());        Hello hello = new Hello();        hello.hashCode();        log.info("hello obj status:{}", ClassLayout.parseInstance(hello).toPrintable());    }}

运行结果：

果然，为了对齐 8 字节，多了 4 字节的填充，整个对象实例大小变成了 24 字节。

3、数组类型的对象结构

数组类型的对象和普通的对象肯定不一样，甚至在对象头中专门有个“数组长度”来记录数组的长度。改变下启动类，看看 Integer 数组的对象结构

import lombok.extern.slf4j.Slf4j;import org.openjdk.jol.info.ClassLayout;import org.openjdk.jol.vm.VM;
/** * @author kdyzm * @date 2024/9/19 */@Slf4jpublic class JalTest {
    public static void main(String[] args) {        log.info(VM.current().details());        Integer[] a = new Integer[]{1, 2, 3};        a.hashCode();        log.info("hello obj status:{}", ClassLayout.parseInstance(a).toPrintable());    }}

输出结果

标红部分相对于普通的对象，数组对象多了个数组长度的字段；而且接下来 3 个整数，共占据了 12 字节大小的内存空间。

再仔细看看，加上数组长度部分，对象头部分一共占据了 16 字节大小的空间，这个和上面的 Array base offsets 的大小一致，这是因为要想访问到真正的对象值，从对象开始要经过 16 字节的对象头才能读取到对象，这 16 字节也就是每个元素读取的“偏移量”了。

4、指针压缩

开启指针压缩： -XX:+UseCompressedOops

关闭指针压缩： -XX:-UseCompressedOops

在 Intelij 中，在下图中的 VM Options 中添加该参数即可

需要注意的是，指针压缩在 java8 及以后的版本中是默认开启的。

接下来看看指针压缩在开启和没开启的情况下，相同的解析代码打印出来的结果

代码：

import lombok.extern.slf4j.Slf4j;import org.openjdk.jol.info.ClassLayout;import org.openjdk.jol.vm.VM;
/** * @author kdyzm * @date 2024/9/19 */@Slf4jpublic class JalTest {
    public static void main(String[] args) {        log.info("\n{}",VM.current().details());        Integer[] a = new Integer[]{1, 2, 3};        a.hashCode();        log.info("hello obj status:\n{}", ClassLayout.parseInstance(a).toPrintable());    }}

开启指针压缩的解析结果：

未开启指针压缩的结果：

以开启指针压缩后的结果为基础，观察下未开启指针压缩的结果

需要注意的是这里的 Integer[]数组里面都是 Integer 对象，而非 int 类型的数值，它是 Integer 基本类型包装类的实例，这里的数组内存地址中存储的是每个 Integer 对象的指针引用，从输出的 VM 信息的对照表中，“ref”类型占据 8 字节，所以才是 3*8 为 24 字节大小。

可以看到，开启指针压缩以后，会产生两个影响

1. 对象引用类型会从 8 字节变成 4 字节

2. 对象头中的 Class Pointer 类型会从 8 字节变成 4 字节

确实能节省空间。

五、扩展阅读

1、大端序和小端序

大端序（Big Endian）和小端序（Little Endian）是两种不同的存储数据的方式，特别是在多字节数据类型（比如整数）在计算机内存中的存储顺序方面有所体现。

• 大端序（Big Endian）：在大端序中，数据的高位字节存储在低地址，而低位字节存储在高地址。类比于数字的书写方式，高位数字在左边，低位数字在右边。因此，数据的最高有效字节（Most Significant Byte，MSB）存储在最低的地址处。

• 小端序（Little Endian）：相反地，在小端序中，数据的低位字节存储在低地址，而高位字节存储在高地址。这种方式与我们阅读数字的顺序一致，即从低位到高位。因此，数据的最低有效字节（Least Significant Byte，LSB）存储在最低的地址处。

这两种存储方式可以用一个简单的例子来说明：

假设要存储一个 4 字节的整数 0x12345678：

• 在大端序中，存储顺序为 12 34 56 78。

• 在小端序中，存储顺序为 78 56 34 12。

2、老版本的 JOL

老版本的 JOL（0.15 之前）输出的值是小端序的，可以做个实验，将 maven 坐标改成 0.14 版本

<!--Java Object Layout --><dependency>    <groupId>org.openjdk.jol</groupId>    <artifactId>jol-core</artifactId>    <version>0.14</version></dependency>

同时要引入新的工具类

<dependency>    <groupId>cn.hutool</groupId>    <artifactId>hutool-all</artifactId>    <version>5.8.32</version></dependency>

然后修改 Hello 类

import cn.hutool.core.util.ByteUtil;import cn.hutool.core.util.HexUtil;
/** * @author kdyzm * @date 2024/9/19 */public class Hello {
    private int a = 1;    private int b = 2;
    public String hexHash() {        //对象的原始 hashCode，Java默认为大端模式        int hashCode = this.hashCode();        //转成小端模式的字节数组        byte[] hashCode_LE = ByteUtil.intToBytes(hashCode, ByteOrder.LITTLE_ENDIAN);        //转成十六进制形式的字符串        return HexUtil.encodeHexStr(hashCode_LE);    }}

启动类：

import lombok.extern.slf4j.Slf4j;import org.openjdk.jol.info.ClassLayout;import org.openjdk.jol.vm.VM;
/** * @author kdyzm * @date 2024/9/19 */@Slf4jpublic class JalTest {
    public static void main(String[] args) {        log.info("\n{}", VM.current().details());        Hello hello = new Hello();        log.info("算的十六进制hashCode：{}", hello.hexHash());        log.info("JOL解析工具输出对象结构:{}", ClassLayout.parseInstance(hello).toPrintable());    }}

输出结果：

先不管老版本的输出和新版本的差异性，总之可以看到小端序手动算的 hashCode 和 jol 解析得到的 hashCode 是一致的，说明老版本的 jol（0.15 之前）输出是小端序的，对应我们的 Mark Word 图例来看

我们的图例是按照大端序来画的，所以老版本的输出第一个字节 01 才是 Mark Word 上述图例的最后一个字节。

代码不变，改变 JOL 版本号为 0.15

<!--Java Object Layout --><dependency>    <groupId>org.openjdk.jol</groupId>    <artifactId>jol-core</artifactId>    <version>0.15</version></dependency>

运行结果如下

可以看到手动计算的 hashCode 和 jol 解析的 hashCode 字节码颠倒过来了，也就是说，从 0.15 版本号开始，jol 的输出变成了大端序输出了。

3、hutool 的 bug

上面的代码中有用到 hutool 工具类计算 hashCode 值的十六进制字符串，一开始我引入的依赖是这样的

<dependency>    <groupId>cn.hutool</groupId>    <artifactId>hutool-all</artifactId>    <version>5.7.3</version></dependency>

其中有个很重要的 int 类型转换字节数组的方法：cn.hutool.core.util.ByteUtil#intToBytes(int, java.nio.ByteOrder)

源代码这样子：

很明显的 bug，它判断了小端序标志，但是却返回了大端序的字节数组，不出意外的，我的代码运行的有矛盾。。所以我专门去 gitee 上看了下，发现它的 master 代码已经发生了变化

没错，它 master 代码已经修复了。。找了找 commit，发现了这个

对应的 COMMIT 记录链接：https://gitee.com/dromara/hutool/commit/d4a7ddac3b30db516aec752562cae3436a4877c0

还被人吐槽了，哈哈哈，引入 5.8.32 版本就解决了

<dependency>    <groupId>cn.hutool</groupId>    <artifactId>hutool-all</artifactId>    <version>5.8.32</version></dependency>

文章转载自：狂盗一枝梅

原文链接：https://www.cnblogs.com/kuangdaoyizhimei/p/18422634

体验地址：http://www.jnpfsoft.com/?from=infoq