对象头MarkWord是Java虚拟机中用于存储对象元数据的重要部分，它包含了哈希码、类元信息、锁状态等信息。通过观察MarkWord的变化，可以了解synchronized锁的升级过程。1.MarkWord的结构在HotSpotJVM中，对象头（ObjectHeader）由两部分组成：MarkWord：存储对象的元信息。KlassPointer：指向对象的类元数据。MarkWord的具体结构取决

本文深入剖析了Java中synchronized锁升级机制在对象头MarkWord层面的底层表现，通过JOL工具实操演示如何精准捕获偏向锁（101）、轻量级锁（000）到重量级锁（010）的完整演进过程，同时揭示了常见误区——锁升级不仅由多线程竞争触发，单线程下跨线程获取已偏向对象同样会引发撤销与升级；文章还直击实践难点：JOL无法可靠显示重量级锁的真实MarkWord（因其指针位于堆外），并强调必须严格控制GC、JIT优化、线程一致性等干扰因素，才能在内存布局中稳定观测锁状态变迁的每一帧真相。

用 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 查看线程栈，如果看到 - 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 干预的字节码执行路径。

好了，本文到此结束，带大家了解了《对象头MarkWord是Java虚拟机中用于存储对象元数据的重要部分，它包含了哈希码、类元信息、锁状态等信息。通过观察MarkWord的变化，可以了解synchronized锁的升级过程。1.MarkWord的结构在HotSpotJVM中，对象头（ObjectHeader）由两部分组成：MarkWord：存储对象的元信息。KlassPointer：指向对象的类元数据。MarkWord的具体结构取决于JVM的实现和对象的锁状态。在64位JVM中，MarkWord通常是64位的，其结构如下（以偏向锁为例）：|指针|0~31位|32~63位||---------------------|---------|----------||偏向锁|线程ID|epoch||轻量级锁|栈帧地址|0||重量级锁|monitor地址|0|2.synchronized锁的升级过程synchronized在Java中使用的是偏向锁->轻量级锁->重量级锁的升级机制。下面详细说明每个阶段MarkWord的变化：**1.》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！