JOL无法稳定捕捉锁升级全过程，因其仅解析Java堆内结构，而重量级锁指针在C++堆、轻量级锁地址在栈帧且易被JIT优化，偏向撤销时Mark Word可能被置零或全1；需禁用逃逸分析与JIT优化，单线程内分步新建对象并即时抓取布局，结合jstack验证重量级锁。
直接看 ClassLayout.parseInstance(obj).toPrintable() 打印出的十六进制值，无法稳定捕捉锁升级全过程——因为 JOL 本身不控制锁状态，且 JVM 优化、线程调度、GC 干扰会让 Mark Word 值“跳变”或“清零”。必须配合 JVM 参数约束 + 线程行为隔离 + 即时快照，才能让低 3 位（锁标识）真实反映当前状态。
为什么 JOL 输出的 Mark Word 常常“不准”或“全零”
JOL 只解析 Java 堆内结构，而重量级锁的 ObjectMonitor* 指针存在 C++ 堆，JOL 读不到真实地址；轻量级锁的栈中 Lock Record 地址在栈帧里，对象头只存指针值，但该指针可能被 JIT 优化掉或因线程退出而失效；偏向锁撤销时若发生 safepoint，Mark Word 可能被临时写为 0x0 或 0xffffffffffffffff。
- 常见错误现象：
0x0000000000000000或0xffffffffffffffff不代表无锁，很可能是重量级锁或撤销中态 - 必须禁用逃逸分析：
-XX:-DoEscapeAnalysis，否则对象可能被栈上分配，根本不在堆中 - 必须禁用 JIT 预热干扰：
-Xint（解释执行）或-XX:+TieredStopAtLevel=1，避免方法被快速编译后内联/优化掉同步块 - 不要复用同一个
Object引用多次观察——每次状态变更后都应新建对象并立即抓取布局
触发并捕获无锁 → 偏向锁 → 轻量级锁的三步实操
这三阶段可在单线程内完成，关键是控制“谁先占坑”和“谁后抢锁”。偏向锁不是靠竞争触发，而是靠“非持有线程尝试加锁”触发撤销+升级。
- 无锁：新建
Object o = new Object()后立刻调用ClassLayout.parseInstance(o).toPrintable()，末尾两位是01，倒数第三位是0（即001） - 偏向锁：在**同一 JVM 进程、同一 main 线程**中，对
o执行一次synchronized(o) { }，再立即抓布局；末尾三位变为101（注意：需提前启用偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0） - 轻量级锁：另起一个新
Object o2 = new Object()，先在子线程中加锁（让它偏向子线程），然后在 main 线程中对o2执行synchronized——此时会触发偏向撤销，并升级为轻量级锁，Mark Word 末尾三位变成000，高位是类似0x0000000800000000的栈地址（非零且非全 1）
重量级锁不能靠 JOL “看出来”，得换验证方式
JOL 几乎无法可靠显示重量级锁的 Mark Word，因为 monitor 指针不在 Java 堆。你看到的 0x0000000000000000 或高位全 1 的值，只是 JVM 在膨胀过程中的中间态或 fallback 值。
- 真正确认是否进入重量级锁，要结合
jstack -l：如果线程状态出现java.lang.Thread.State: BLOCKED (on object monitor)或- waiting to lock，且锁地址与目标对象一致，就是重量级 - 加
-XX:+PrintGCDetails -XX:+PrintSafepointStatistics，若频繁出现no vm operation阻塞，大概率是 monitor 争用导致 safepoint 卡顿 - 不要依赖
System.identityHashCode(o)后再加锁——调用它会强制将 Mark Word 中的 hashcode 位固化，干扰偏向锁启用（偏向锁要求 hashcode 未计算过）
最易被忽略的一点：所有观察必须在对象“刚创建、未被 GC 标记、未被 JIT 编译优化”的窗口期内完成。一旦错过，Mark Word 就不是你代码写的那个状态了——它可能已经被 GC 清洗、被编译器重排、或被 monitor 膨胀覆盖。别指望一次运行看到全部四阶段，分段、隔离、即时抓取才是关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
