Java对象头存储锁状态、哈希码、GC年龄、类型指针等元数据，不存变量；32位JVM中为8字节，64位默认压缩指针下为12字节（Mark Word 8B + Klass Pointer 4B），对齐后空对象占16字节。

Java 对象头本身不存变量，它存储的是对象自身的元数据：比如锁状态、哈希码、GC 分代年龄、类型指针等。所谓“变量元数据”实际是误称——真正和变量相关的（如局部变量、参数）在栈帧中，而对象头只服务于堆中对象的生命周期与同步管理。重点在于：对象头大小直接受 JVM 位宽与是否启用指针压缩影响，这决定了每个对象的固定内存开销。

32 位 JVM 的对象头结构

在纯 32 位 HotSpot JVM 下：

• Mark Word 占 4 字节（32 位），存放哈希码、锁标志、分代年龄等信息
• Klass Pointer（类元数据指针）占 4 字节，指向方法区中的 Class 对象
• 对象头合计 8 字节
• 对象整体按 8 字节对齐，空对象（如 new Object()）最小占用仍为 8 字节（无实例字段 + 无填充）

64 位 JVM 默认开启指针压缩（CompressedOops）

JDK 7u40 及之后版本，64 位 Server VM 默认启用 -XX:+UseCompressedOops。此时：

• Mark Word 保持 8 字节（64 位），结构更丰富（支持偏向锁、epoch 等）
• Klass Pointer 被压缩为 4 字节（而非原生 8 字节），前提是堆内存 ≤ 32GB
• 对象头合计 12 字节
• 对象仍按 8 字节对齐，但因头为 12 字节，需补 4 字节 padding → 实际占用至少 16 字节（如 new Object()）

64 位 JVM 关闭指针压缩的情况

当显式添加 -XX:-UseCompressedOops 或堆超过 32GB 导致压缩失效时：

• Mark Word 仍为 8 字节
• Klass Pointer 回归原生 8 字节
• 对象头达 16 字节
• 对齐后，空对象最小占用升至 16 字节（16 % 8 == 0，无需额外 padding）
• 大量小对象场景下，内存占用比 32 位 JVM 高出约 50% —— 主因是指针翻倍 + 对齐放大

为什么“重量”差异会影响实际应用

对象头不是孤立存在，而是每个对象的强制开销：

• 创建百万个 DTO 或集合元素时，12 字节 vs 16 字节头，差额可达数百 MB
• 数组对象额外携带 4 字节长度字段，头结构也不同（如 Object[] 在 64 位压缩模式下头为 12 字节 + 4 字节 length → 16 字节，再对齐）
• GC 扫描、复制、标记均需处理对象头，更大的头意味着更多缓存行压力和带宽消耗
• 虽然现代服务器内存充足，但在高吞吐低延迟系统（如金融交易、实时风控）中，这部分“隐性成本”会累积成可观的性能扰动