Java Compact Object Headers 会怎样改变对象布局

Java Compact Object Headers 改变的不是 Java 字段，而是 HotSpot 在每个堆对象前面保存元数据的方式：传统布局把 mark word 和 class word 分开，紧凑布局把压缩后的类指针收进一个 64 位头部。对大量小对象的服务来说，收益主要来自更小的对象尺寸、更好的缓存局部性和更低的 GC 压力；它不会把业务对象自动变成值类型，也不会替换数组长度等对象内容。

官方资料：https://openjdk.org/jeps/519

从两段头部到一个64位头部

传统 HotSpot 对象头通常由 mark word 和 class word 组成。mark word 承担锁状态、身份哈希码和 GC 年龄等信息；class word 保存对象所属类的指针。64 位进程启用压缩类指针时，普通实例常见的是 64 位 mark word 加 32 位 class word，再按对象对齐补齐，因此一个空对象仍可能占 16 字节。

Compact Object Headers 的核心变化是取消这两个逻辑字的分割，把压缩类指针放进同一个 64 位头部。JEP 450 给出的目标是让 x64 和 AArch64 上的头部固定为 8 字节；对象的字段、数组元素和数组长度编码并没有因此改写。对象越小，头部占总尺寸的比例越高，节省越容易体现在堆容量和缓存访问上。

压缩类指针如何挤进对象头

紧凑布局不是简单删除 class word，而是重新分配位段。压缩类指针占据头部高位，身份哈希码、对象年龄、状态标记和为 Project Valhalla 预留的位共同使用剩余空间。JEP 450 将压缩类指针从原来的 32 位编码收缩到 22 位，这也是紧凑头部依赖 -XX:+UseCompressedClassPointers 的原因。

因此，“对象头变小”不等于“所有 JVM 都能使用”。关闭压缩类指针、加载极大量类、使用不兼容的 JVMCI 路径，都会改变启用条件。类加载规模和运行时组件要在灰度环境中先确认，不能只复制一个启动参数。

对锁、GC和部署边界的影响

紧凑头部保留类型信息后，轻量级锁可以通过翻转标记位表示，竞争或调用 wait()、notify() 时再进入监视器锁路径。传统 stack-locking 会用指针覆盖对象头，这会破坏类信息，所以该机制与紧凑头部不兼容；JVM 会在冲突配置下关闭紧凑布局。

GC 方面，复制阶段仍要把旧对象映射到新对象，滑动整理阶段也要暂存转发信息。由于每个紧凑头都包含类信息，不能像旧布局那样只为少量“有趣头部”保存副本。非 ZGC 收集器在超过约 8TB 堆时存在转发编码边界，JEP 450 明确把这类超大堆列为限制。这里的收益和代价都属于 HotSpot 实现细节，不能外推成 Java 语言层面的保证。

版本判断也要分开写。JDK 25 通过 -XX:+UseCompactObjectHeaders 显式启用，JDK 27 的 JEP 534 则将其设为默认布局，并保留 -XX:-UseCompactObjectHeaders 作为回退开关。启动参数示例：

# JDK 25：显式打开紧凑对象头，先在灰度环境使用
java -XX:+UseCompactObjectHeaders -Xms2g -Xmx2g -jar app.jar

# JDK 27：需要诊断回退时显式关闭紧凑对象头
java -XX:-UseCompactObjectHeaders -Xms2g -Xmx2g -jar app.jar

迁移时先做什么

第一步不是调大或调小堆，而是建立同一业务负载的基线：记录堆峰值、Full GC/Young GC 次数、暂停时间、CPU、锁竞争和启动失败原因。第二步固定 JDK、GC、容器内存和类路径，只切换对象头开关。第三步用对象数量多、单对象小的接口压测，同时覆盖缓存、序列化、反射和大量类加载路径。

如果收益只出现在空对象数量极高的基准，而真实服务的堆峰值与延迟没有改善，就不应为了“头部更小”强行迁移；如果出现 JVMCI、锁、GC 或类加载异常，则先保留回退开关，并把问题归因到运行时边界，而不是修改业务对象字段。

常见问题

Compact Object Headers 会减少 Java 对象字段吗？

不会。它压缩的是 HotSpot 对象头，实例字段、数组元素和数组长度的编码不因该特性自动改变。

JDK 25 是否默认启用紧凑对象头？

JDK 25 仍需要 -XX:+UseCompactObjectHeaders 显式开启；JDK 27 的 JEP 534 才把它设为默认布局。

为什么开启后堆没有明显下降？

对象头只占对象总尺寸的一部分。若对象本身很大、堆中数组占比高，或压缩类指针条件不满足，整体收益就会被字段和对齐开销稀释。