跳至主要內容

Java 对象内存布局深度揭秘——压缩指针、对象头、内存对齐全解析

老张2026/4/30大约 7 分钟

Java 对象内存布局深度揭秘——压缩指针、对象头、内存对齐全解析

适读人群：想深入理解 Java 对象在内存中真实样子的工程师 | 阅读时长：约16分钟 | 核心价值：理解 Java 对象内存布局的每一个字节，掌握内存优化和并发锁升级的底层原理

一、一个让我惊讶的数字

刚工作那年，我以为 Java 的一个空对象 new Object() 就占 8 个字节。后来看了《深入理解 Java 虚拟机》，才知道一个空对象在 64 位 JVM 上占 16 个字节——其中对象头就占了 12 个字节，哪怕这个对象里没有一个字段。

这个发现让我开始重新思考内存使用。一个有 3 个 int 字段的对象，理论上字段只需要 12 字节，但实际上它在内存里占了多少？JVM 的内存对齐规则是怎么工作的？synchronized 锁的信息存在哪里？为什么有时候一个字段的偏移量不是连续的？

这些问题背后有一套完整的对象内存布局规则。搞清楚这套规则，你才能做真正有效的内存优化，才能理解偏向锁、轻量级锁的实现原理。

二、JVM 对象内存布局的三部分

在 HotSpot JVM 中，一个 Java 对象在内存里由三部分组成：

┌─────────────────────────────────────────┐
│  对象头 (Object Header)                  │
│  ├── Mark Word (8 bytes)                 │
│  └── Klass Pointer (4 bytes / 8 bytes)  │
├─────────────────────────────────────────┤
│  实例数据 (Instance Data)                │
│  （各字段的实际数据）                     │
├─────────────────────────────────────────┤
│  对齐填充 (Padding)                      │
│  （让对象总大小是 8 的倍数）              │
└─────────────────────────────────────────┘

2.1 Mark Word（8 字节）

Mark Word 是对象头最核心的部分，同一个 8 字节在不同状态下存储的内容不同：

锁状态存储内容
无锁对象的 hashCode（31位）+ GC 分代年龄（4位）+ 偏向锁位（0）+ 锁标志位（01）
偏向锁持有偏向锁的线程 ID + 偏向时间戳 + GC 分代年龄 + 偏向锁位（1）+ 锁标志位（01）
轻量级锁指向栈帧中锁记录的指针 + 锁标志位（00）
重量级锁指向 Monitor 对象的指针 + 锁标志位（10）
GC 标记锁标志位（11）

这里有个非常重要的含义：一个对象在调用 hashCode() 之后，hashCode 就存在 Mark Word 里了。如果这个对象随后被加上偏向锁，偏向锁状态下 Mark Word 没有空间存 hashCode，所以已经计算过 hashCode 的对象无法进入偏向锁状态，会直接升级为轻量级锁。

2.2 Klass Pointer（类型指针）

Klass Pointer 指向这个对象的类元数据（在 Metaspace 里），JVM 通过它知道这个对象是哪个类的实例。

在 64 位 JVM 上，指针原本是 8 字节，但开启压缩指针（-XX:+UseCompressedOops，Java 7+ 默认开启）后，Klass Pointer 压缩为 4 字节，节省了内存。

2.3 数组对象额外多一个 length 字段

数组对象在 Klass Pointer 之后还有 4 字节的数组长度，这就是为什么 int[] arr = new int[0] 占 16 字节，而普通空对象也是 16 字节。

三、用 JOL 工具查看真实内存布局

说了这么多理论，不如直接用工具看。JOL（Java Object Layout）是专门用来分析对象内存布局的工具。

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.17</version>
</dependency>
package com.example.jol;

import org.openjdk.jol.info.ClassLayout;
import org.openjdk.jol.vm.VM;

/**
 * 用 JOL 分析不同对象的内存布局。
 * 帮助你理解对象头、字段排列、内存对齐的实际情况。
 */
public class ObjectLayoutDemo {

    /**
     * 一个有不同类型字段的测试类。
     * 字段的排列顺序在内存中不一定和声明顺序相同，JVM 会重新排列以减少内存浪费。
     */
    static class MixedFields {
        boolean flag;    // 1 byte
        long bigNum;     // 8 bytes
        int count;       // 4 bytes
        byte smallByte;  // 1 byte
        String name;     // 4 bytes（压缩指针）或 8 bytes（非压缩）
    }

    public static void main(String[] args) {
        System.out.println(VM.current().details());
        System.out.println("=====================================");

        // 分析 MixedFields 的内存布局
        System.out.println(ClassLayout.parseClass(MixedFields.class).toPrintable());
        System.out.println("=====================================");

        // 分析加锁前后的 Mark Word 变化
        Object lock = new Object();
        System.out.println("加锁前：");
        System.out.println(ClassLayout.parseInstance(lock).toPrintable());

        synchronized (lock) {
            System.out.println("加锁中（轻量级锁/偏向锁）：");
            System.out.println(ClassLayout.parseInstance(lock).toPrintable());
        }

        System.out.println("加锁后：");
        System.out.println(ClassLayout.parseInstance(lock).toPrintable());
    }
}

MixedFields 的 JOL 输出大致如下：

com.example.jol.ObjectLayoutDemo$MixedFields object internals:
OFF  SZ               TYPE DESCRIPTION               VALUE
  0   8                    (object header: mark)      0x0000000000000001 (non-biasable; age: 0)
  8   4                    (object header: class)     0x00060628
 12   4                int MixedFields.count          0
 16   8               long MixedFields.bigNum         0
 24   1            boolean MixedFields.flag           false
 25   1               byte MixedFields.smallByte      0
 26   2                    (alignment/padding gap)    
 28   4   java.lang.String MixedFields.name           null
Instance size: 32 bytes

注意几点：

  1. 对象头共 12 字节（Mark Word 8 + Klass Pointer 4，开启压缩指针）
  2. 字段顺序被 JVM 重排了：int 和 long 排在前面，boolean 和 byte 聚在一起
  3. 第 26~27 字节有 2 字节的填充对齐
  4. 总大小 32 字节，是 8 的倍数（内存对齐要求）

四、内存对齐规则

HotSpot JVM 要求对象总大小是 8 字节的倍数（可以通过 -XX:ObjectAlignmentInBytes 修改，最小 8，最大 256）。如果对象的实际内容不足 8 的倍数，会在末尾加 Padding 填充。

为什么要对齐？对齐访问可以让 CPU 用单次内存读取操作获取完整数据，不用跨两个 Cache Line，提升内存访问效率。不对齐的访问在某些 CPU 架构上还会触发硬件异常。

字段的对齐规则：

  • long/double（8 字节）要求在 8 字节边界对齐
  • int/float（4 字节）要求在 4 字节边界对齐
  • short/char（2 字节）要求在 2 字节边界对齐
  • byte/boolean（1 字节）无对齐要求

JVM 会对字段重排以减少 Padding 浪费，通常的排列顺序是：long/double → int/float → short/char → byte/boolean → 引用类型。

五、压缩指针对内存的影响

开启压缩指针（默认开启，堆 <= 32G）时：

  • 普通对象引用从 8 字节压缩到 4 字节
  • Klass Pointer 从 8 字节压缩到 4 字节

对于有大量对象引用的系统，开启压缩指针能节省 20%~40% 的堆内存。

# 验证压缩指针是否开启
java -XX:+PrintFlagsFinal -version 2>&1 | grep UseCompressedOops

注意：当堆内存超过 32G（准确是 32760 MB），压缩指针自动关闭，所有引用从 4 字节变回 8 字节，内存使用会突然增加。这就是为什么很多推荐在 JVM 堆上用 28G 而不是 32G——留出余量，确保压缩指针有效。

六、踩坑实录

坑1：以为 Java 对象节省内存，实际很浪费

现象：系统内存占用比预估的高出 2~3 倍，做了堆分析之后发现大量小对象。

原因：不了解对象头的开销。一个只有 1 个 int 字段的对象，理论上 4 字节，但实际占 16 字节（12 字节对象头 + 4 字节字段，恰好对齐）。如果这样的对象有 1000 万个，就是 160MB，而"有效数据"只有 40MB。

解法：对大量小对象场景，考虑以下方案：

  1. 用原生数组（int[], long[]）代替对象数组，彻底消除对象头开销
  2. 用 Protobuf/FlatBuffers 等二进制序列化格式作为数据容器
  3. 合并小对象，减少对象数量

坑2：hashCode 破坏偏向锁优化

现象：用 synchronized 做短暂的锁操作，但通过 JOL 观察发现锁直接是轻量级锁，没有经过偏向锁阶段，而同样的代码在另一个类上却有偏向锁。

原因：某个地方调用了对象的 hashCode() 方法（比如把对象放进了 HashMap），导致 hashCode 已经写入 Mark Word，对象无法再进入偏向锁状态。这个坑我也踩过，当时排查锁竞争问题时发现偏向锁失效，追了好久才找到这个原因。

解法：如果对象同时作为锁和 HashMap 的 key，这个场景不适合偏向锁优化。调整设计，让锁对象和数据对象分离。

坑3：堆超过 32G 导致内存暴涨

现象：给服务从 28G 堆扩容到 36G，期望多出 8G 空间，但实际上 RSS 从 35G 涨到了 50G，内存使用比预期多得多。

原因：堆超过 32G 之后，压缩指针关闭，所有引用从 4 字节变成 8 字节，这个服务有大量对象，引用数量极多，导致内存突然暴涨。

解法：保持堆在 28G 或以下（开启压缩指针），如果需要更多内存，考虑横向扩容（多个 JVM 实例）而不是纵向扩容单个实例超过 32G。

七、内存优化实践建议

  1. 合理设计数据结构：减少不必要的包装对象，int 比 Integer 省 12 字节
  2. 大量同类小对象用对象池：避免对象频繁创建销毁，减少 GC 压力
  3. 字段类型选择：能用 int 就不用 long，能用 byte 就不用 int
  4. 字段排列优化：把相同类型的字段放在一起，减少 Padding 浪费
  5. 保持堆 <= 28G：确保压缩指针有效，节省引用类型的内存开销
编辑此页
最近更新:
贡献者: xiaozhangge