64位HotSpot虚拟机中对象头默认占12字节，即8字节Mark Word（动态复用存储哈希码、锁状态、GC年龄等）加4字节压缩后的Klass Pointer。
JVM 对象头在 64 位 HotSpot 虚拟机中默认占用 12 字节（非压缩指针场景下），但实际 Mark Word 本身是 8 字节（64 bit），另 4 字节为 类型指针（Klass Pointer）。所谓“12 字节 Header”，即指对象头总大小 = Mark Word（8 字节） + Klass Pointer（4 字节）。关键在于：这 8 字节的 Mark Word 并非静态固定存储，而是通过复用+动态解释方式，在不同生命周期阶段承载不同语义的数据。
Mark Word 的动态复用机制
64 位 Mark Word 共 64 bit，其字段含义随对象锁状态和 GC 状态动态切换。核心字段共存但互斥使用：
- 锁状态标志（2 bit）：决定后续 bits 的解读方式，取值 01（无锁）、00（偏向锁）、10（轻量级锁）、11（重量级锁/膨胀后）
- GC 分代年龄（4 bit）：仅在对象处于“无锁”或“已晋升”状态时有效，范围 0–15；达到 15 后下次 Minor GC 就进入老年代
-
哈希码（31 bit）：仅当对象未被加锁、且
hashCode()方法首次被调用后才写入；若之后发生锁升级（如偏向→轻量级），原哈希码会被移出并存入对象实例数据区的特定偏移位置（避免覆盖） - 其余位用于存储偏向线程 ID（54 bit）、偏向时间戳（31 bit，与线程 ID 共享空间）、重量级锁指针（64 bit 指向 Monitor 对象）等——这些字段与哈希码、分代年龄不同时存在
为什么能塞进 8 字节？靠状态驱动的位域重映射
HotSpot 不为每个字段分配固定位置，而是按锁状态划分 Mark Word 的语义布局：
- 无锁态（01）：高 31 位存 hashCode（若已计算），低 4 位存 age，再低 2 位为锁标志，剩余位填充或保留
- 偏向锁态（00）：高 54 位存 thread ID，中间 1 位 epoch，低 4 位 age，低 2 位锁标志——此时 hashCode 不在 Mark Word 中
- 轻量级锁态（10）：64 位全作栈中 Lock Record 地址，hashCode 和 age 均已移出
- 重量级锁态（11）：64 位指向堆中 ObjectMonitor 地址，所有运行时数据均由 Monitor 托管
实际验证：对象头内容会随操作实时变化
例如一个新创建对象：
- 刚 new 出来：Mark Word 低 2 位为 01（无锁），age=0，hashCode 未生成 → 对应位全 0
- 调用
obj.hashCode()后：31 位填入计算值（如 0x12345678），age 仍为 0，锁标志保持 01 - 被线程 A 偏向后：锁标志变 00，高 54 位写入 A 的 thread ID，age 仍可读
- 发生竞争导致撤销偏向：锁标志变 10，原 hashCode 若未迁移，会触发一次“hash 移出”动作，写入对象实例数据起始前的预留 slot
补充说明：12 字节 ≠ 固定结构
注意：12 字节是开启 -XX:+UseCompressedClassPointers（默认开启）下的常见大小。若关闭该参数，Klass Pointer 升为 8 字节，对象头变成 16 字节；若还关闭指针压缩（-XX:-UseCompressedOops），引用字段也变宽，整体布局进一步变化。但 Mark Word 的 8 字节动态复用逻辑不变。
