JOL可查看对象头MarkWord原始值，但需满足未被GC回收、未被JIT优化、锁操作在同一线程等条件；偏向锁MarkWord低3位为101，轻量级锁为000，重量级锁低3位010但JOL通常无法准确显示。
用 JOL 查看对象头 MarkWord 的原始值
Java 对象头里的 MarkWord 是锁状态的底层载体，但 JVM 不对外暴露直接读取接口，得靠第三方工具反推。最常用的是 org.openjdk.jol:jol-core，它能打印对象在内存中的布局，包括对象头各字段的十六进制值。
关键点在于：必须在「对象未被 GC 回收、未被 JIT 优化重排、且锁操作发生在同一线程内」的前提下观察，否则 MarkWord 值会被干扰或不可见。
- 启动 JVM 时加参数：
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0（启用偏向锁并取消延迟） - 确保测试代码在 main 线程中执行（避免线程 ID 不一致导致偏向锁失败）
- 每次修改锁状态后，立即调用
ClassLayout.parseInstance(obj).toPrintable()，不要复用对象引用
偏向锁 → 轻量级锁的触发条件与 MarkWord 变化
偏向锁升级为轻量级锁，不是靠“竞争”，而是靠「一个线程尝试获取已偏向给其他线程的锁」。也就是说，即使只有一个线程，只要它对「已被偏向给别的线程的对象」执行 synchronized，就会触发撤销+升级流程。
典型错误认知是“多线程竞争才升级”，其实单线程下也能看到升级——只要你先让对象偏向 A 线程，再用 B 线程去 synchronized 它（哪怕 B 是 main 线程且 A 已退出）。
- 偏向锁状态时，
MarkWord低 3 位是101，高 54 位存偏向线程 ID（需注意线程 ID 在 JVM 内部是 hash 值，不是 OS PID） - 轻量级锁状态时，低 3 位变成
000，原位置存指向栈中Lock Record的指针（在堆上打印出来是类似0x0000000800000000这样的地址值） - 撤销偏向锁会触发
biased_lock_revocation日志（加-XX:+PrintBiasedLockingStatistics可确认）
为什么 JOL 看不到重量级锁的 MarkWord？
重量级锁（monitor）状态下，MarkWord 会被替换为指向 ObjectMonitor* 的指针，但这个指针本身存储在堆外（C++ 堆），JOL 默认只解析 Java 堆内的结构，所以打印出来的 MarkWord 值常常是 0x0000000000000000 或看似随机的高位全 1 值（如 0xffffffffffffffff），不代表真实 monitor 地址。
真正要确认是否进入重量级，不能只看 JOL 输出，得结合：
-
-XX:+PrintGCDetails和-XX:+PrintSafepointStatistics中是否出现大量no vm operation阻塞（重量级锁争用会导致 safepoint 频繁） - 用
jstack -l <pid>查看线程栈，如果看到- waiting to lock <0x...>并伴随java.lang.Thread.State: BLOCKED，基本可断定是重量级锁 -
MarkWord低 3 位为010是重量级锁标识，但该值只有在锁膨胀完成后的极短时间内可见；一旦 monitor 初始化完毕，JVM 可能用其它方式隐藏该字段
实战中容易忽略的三个细节
锁升级过程不是原子的，中间存在多个中间态，而很多调试手段会跳过这些瞬间。比如用 JOL 打印两次之间隔了 GC 或 JIT 编译，MarkWord 就可能被重写或优化掉。
- 不要在循环里反复
synchronized同一个对象——JIT 可能做锁消除（-XX:+EliminateLocks默认开启），导致根本看不到锁信息 - 禁止使用
System.gc()或显式触发 GC，GC 过程中对象可能被移动，MarkWord会被重置或覆盖 - 64 位 JVM 下，
MarkWord是 64 bit，但开启压缩指针（-XX:+UseCompressedOops）时，其中部分字段含义和位宽会变化；建议统一用-XX:-UseCompressedOops测试，避免位移错位
真正难的不是看到某一种锁状态，而是把「偏向撤销→轻量级加锁→锁膨胀」整条链路在内存层面串起来。每一步都依赖精确的线程调度、无干扰的 GC 状态和未被 JIT 干预的字节码执行路径。
