如何利用对象头的标记位实战理解 synchronized 对变量锁定的底层机制

先说说最关键的一点：synchronized锁的是对象，而不是变量。这个认知一旦建立，很多关于并发编程的困惑就会迎刃而解。锁信息藏在对象的对象头（Header）里，具体来说，是Mark Word中的标记位在发挥作用。Ja va里根本不存在“对变量加锁”这回事，只有“对对象加锁”。变量，尤其是实例变量或静态变量，只是被封装在某个对象中，通过锁住该对象来间接保护其状态。

理解这一点，整个锁机制的逻辑就清晰了。

一、先明确：synchronized 锁的是对象，不是变量

看这段代码：

private int count = 0;
public synchronized void increment() { count++; }

表面上看，像是锁了count变量，但实际锁的是当前实例（this）这个对象。JVM会去读取this对象头里的Mark Word，根据其中的锁状态标志位（比如001=无锁、101=偏向锁、00=轻量级锁、10=重量级锁）来决定如何执行同步逻辑。

同样的道理，静态变量被synchronized静态方法保护时，真正被锁的是MyClass.class这个Class对象，它的对象头同样承载着锁状态。所以，别再被“锁变量”这种说法误导了。

二、用 JOL 工具实测对象头变化，直观看到标记位切换

光说不练假把式。借助JOL（Ja va Object Layout）工具，可以打印对象在内存中的布局，包括Mark Word的原始二进制/十六进制值，从而亲眼验证锁升级过程：

• 新建一个普通对象，未加锁时：Mark Word末三位通常是001（无锁态），包含哈希码或分代年龄
• 让单一线程首次进入synchronized(obj)：JVM尝试设置偏向锁 → Mark Word被写入线程ID + 偏向时间戳 + 末三位变为101
• 再启另一个线程竞争同一把锁：触发偏向撤销 → Mark Word恢复为无锁态（001），随后升级为轻量级锁 → 末两位变为00，高位存指向栈中Lock Record的指针
• 若竞争激烈（自旋失败），升级为重量级锁 → 末两位变为10，高位存指向堆中Monitor对象的指针

这些变化全都发生在同一个对象的对象头上，无需修改代码逻辑，仅靠多线程触发就能完整观察。这就是“变量被保护”的物理基础：不是变量变了，而是它所属对象的头部标记位在动态响应并发行为。

三、为什么不能直接“锁变量”？从内存模型讲清楚

这个问题很有意思。Ja va中的局部变量存在栈帧里，生命周期短、线程私有；实例变量和静态变量虽可共享，但JVM规定：锁机制必须依托于可寻址、有身份、能关联Monitor的实体对象。

Mark Word是JVM设计给每个对象预留的“元数据控制区”，只有这里才能安全、原子地记录锁归属、状态、等待队列等信息。如果强行设计“锁int变量”，就得为每个基本类型分配额外头空间，这既违背内存紧凑原则，也破坏对象一致性模型。

所以，所谓“锁定count”，本质上是这样的链路：
→ 把count放在某个实例对象里
→ 用synchronized(this)锁住该实例
→ JVM修改this的Mark Word标记位并关联Monitor
→ 其他线程想改count，必须先拿到这把锁

四、实战建议：排查锁失效，优先查锁对象是否一致

很多并发bug并非语法写错，而是锁对象不统一。这类问题在实战中非常常见：

• 错误写法：两个线程分别new出不同实例，各自调用synchronized instanceMethod() → 实际锁的是两个不同对象，Mark Word完全独立，毫无互斥效果
• 正确写法：共用同一个实例，或锁MyClass.class，或显式使用private final Object lock = new Object()作为唯一锁对象

调试时，用JOL查看两个“自称”是同一个锁的对象，它们的地址是否一致、Mark Word是否真被同一Monitor关联——这是比日志更底层、更可靠的验证方式。记住，一切的根源都在对象头里。