对象头是 synchronized 锁机制的物理根基，Mark Word 动态复用存储无锁、偏向、轻量级和重量级锁状态，锁升级本质是对其原子修改，字节码指令与对象头强绑定，调试需依赖其状态分析。
对象头是 synchronized 锁机制的物理根基，它不是辅助信息，而是锁状态的直接载体。
Mark Word 存储锁的全部状态
Java 对象头中的 Mark Word（通常 64 位）在不同锁阶段动态复用同一块内存，直接编码当前锁类型：
- 无锁状态：存放哈希码、GC 年龄等常规元数据
- 偏向锁状态：记录偏向线程 ID 和时间戳，避免无竞争时的 CAS 开销
- 轻量级锁状态：保存指向线程栈中 Lock Record 的指针
- 重量级锁状态：替换为指向 ObjectMonitor 的指针
这种“一地多用”的设计让锁升级无需额外分配内存，全靠 Mark Word 的位布局切换实现。
锁升级过程完全依赖对象头变更
synchronized 的锁升级（偏向 → 轻量 → 重量）本质上就是 JVM 对 Mark Word 内容的一系列原子修改：
立即学习“Java免费学习笔记（深入）”；
- 检测到竞争时，JVM 尝试用 CAS 将 Mark Word 从偏向状态更新为轻量级锁结构
- 自旋失败后，再尝试膨胀为重量级锁——将 Mark Word 改写为 Monitor 地址
- 每次变更都以对象头为唯一判断依据，线程通过读取 Mark Word 即可获知当前锁形态
没有对象头，JVM 就无法感知锁状态，整个锁升级逻辑就失去立足点。
字节码指令与对象头强绑定
编译后的 monitorenter 指令，并不直接操作 Monitor，而是先检查并修改对象头：
- 执行 monitorenter 时，JVM 首先读取对象头的 Mark Word，判断锁状态
- 根据当前状态决定走偏向逻辑、自旋逻辑，还是进入 OS 级阻塞
- monitorexit 同样需校验对象头，确保释放的是当前线程持有的那把锁
也就是说，字节码层的同步语义，最终全部落地到对对象头的读-改-写操作上。
调试和排查离不开对象头分析
当遇到锁竞争、死锁或性能瓶颈时，直接观察对象头能快速定位问题根源：
- 用 JOL（Java Object Layout）工具打印对象内存布局，可直观看到 Mark Word 当前值
- 若 Mark Word 中存的是线程 ID，说明处于偏向锁且未撤销；若存的是 Monitor 地址，说明已膨胀
- 线上 dump 出的堆快照中，通过分析对象头状态，可判断是否大量锁已升级为重量级，进而推断是否存在不合理竞争
对象头就像锁的“健康仪表盘”，所有关键指标都集中于此。
