HotSpot中对象头分普通/数组两类，含Mark Word和klass pointer（数组额外有length），64位默认16字节（压缩后12字节但对齐为16），Mark Word动态存储哈希码、锁信息等，klass pointer指向C++ Klass而非Java Class。
对象头在HotSpot里的实际内存布局
Java对象在HotSpot虚拟机中，对象头不是固定8字节或16字节，而是分两种情况：普通对象和数组对象。普通对象的对象头由 Mark Word 和 klass pointer（类型指针）组成；数组对象多一个 array length 字段。32位JVM下对象头最小为8字节，64位默认是16字节——但开启指针压缩（-XX:+UseCompressedOops）后，klass pointer 压缩为4字节，对象头变成12字节（需对齐到8的倍数，所以实际仍占16字节）。
常见错误现象：Unsafe.objectFieldOffset 返回的偏移量不等于“对象头长度”，因为字段偏移是从对象起始地址算起，而对象头本身占据前若干字节，后续实例字段才紧随其后。
- 64位未开启压缩：Mark Word（8字节） + klass pointer（8字节） = 16字节
- 64位开启压缩（默认）：Mark Word（8字节） + klass pointer（4字节） + padding（4字节对齐） = 16字节
- 数组额外字段
array length占4字节，且一定在 klass pointer 之后、实例数据之前
Mark Word里到底存了什么
Mark Word 是对象头中最动态的部分，同一块内存在不同生命周期承载不同语义：刚创建时存哈希码、GC年龄、锁状态标志；加轻量级锁后存指向栈中锁记录的指针；膨胀为重量级锁后存指向 ObjectMonitor 的指针；GC标记阶段可能被复用为标记位。它的结构是位域（bit field），具体布局取决于是否启用偏向锁（-XX:+UseBiasedLocking）以及当前锁状态。
使用场景举例：调用 System.identityHashCode(obj) 第一次会触发 Mark Word 中哈希码位的写入，如果此时对象已处于锁状态，就可能触发锁升级或偏向撤销，带来额外开销。
立即学习“Java免费学习笔记（深入）”；
- 无锁状态（未偏向）：hash（31位） + age（4位） + biased_lock（1位） + lock（2位）
- 偏向锁状态：thread_id（54位） + epoch（2位） + age（4位） + biased_lock（1位） + lock（2位）
- 轻量级锁：指向栈中
Lock Record的指针（64位全用） - 注意：JDK 15+ 默认禁用偏向锁，
biased_lock位恒为0
klass pointer为什么不能直接当Class对象用
klass pointer 是个压缩或非压缩的地址，指向的是 HotSpot 内部的 Klass 结构体（C++ 类），不是 Java 层的 java.lang.Class 实例。后者是 JVM 在堆上创建的普通对象，其 klass pointer 指向 java/lang/Class 对应的 Klass，而该 Klass 里又有个字段（_java_mirror）反向持有一个对那个 Class 对象的引用。
容易踩的坑：用 Unsafe 读取对象头里的 klass pointer 地址，然后试图强制转型成 Class —— 这会失败，因为地址指向的是 native 内存中的 C++ 对象，不是 Java 对象头起始位置。
- 想获取 Class 实例，请始终走
obj.getClass()，不要尝试从对象头“解析”出来 - JVM 可能将
klass pointer存放在对象头末尾（如开启压缩时），也可能因对齐插入 padding，位置不固定 - 通过
WhiteBox.getKlassLayout（需 -XX:+UnlockDiagnosticVMOptions）可查运行时布局，但仅限调试
对象头大小会影响内存占用和缓存行对齐吗
会，而且影响比想象中更实在。对象头大小直接决定每个对象的基线内存开销；更重要的是，它影响对象在内存中的起始地址是否与 CPU 缓存行（通常64字节）对齐。如果对象头+实例字段总长跨缓存行边界，一次字段访问可能触发两次缓存加载。
典型问题：大量小对象（如 AtomicInteger、简单 POJO）在未开启压缩时，64位指针让对象头变大，加上字段填充，更容易导致缓存行错位。开启 -XX:+UseCompressedOops 后，不仅减少指针体积，还提高对象密度，间接改善缓存局部性。
- 对象头本身不会单独对齐，但整个对象（头+字段+padding）会被 JVM 对齐到 8 字节边界
- 若字段总长 + 对象头 ≡ 0 (mod 64)，则最理想；否则建议用
@Contended（需 -XX:-RestrictContended）隔离热点字段 - 不要手动在类里加
long pad1, pad2模拟对齐——JVM 的填充策略更可靠，且不同 GC 算法（如 ZGC）有额外对齐要求
对象头不是规范定义的稳定结构，而是 HotSpot 的实现细节，随 JDK 版本、GC 算法、JVM 参数持续微调。拿 Unsafe 去读写对象头，本质上是在和 JVM 的内部约定打交道，稍有不慎就会在升级后失效或崩溃。
