synchronized锁的是对象而非变量，关键在于对象头Mark Word中的锁状态标志位；通过JOL可验证其从无锁（001）→偏向锁（101）→轻量级锁（00）→重量级锁（10）的动态升级过程。
理解 synchronized 对变量的锁定，关键不在“变量”本身，而在于它背后所依赖的**锁对象**——这个锁信息就藏在该对象的对象头（Header）里，具体是 Mark Word 中的标记位。Java 中没有“对变量加锁”这回事，只有“对对象加锁”，而变量（尤其是实例变量或静态变量）只是被封装在某个对象中，通过锁住该对象来间接保护其状态。
一、先明确：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（Java Object Layout） 工具，可以打印对象在内存中的布局，包括 Mark Word 的原始二进制/十六进制值，从而验证锁升级过程：
- 新建一个普通对象，未加锁时：Mark Word 末三位通常是 001（无锁态），包含哈希码或分代年龄
- 让单一线程首次进入
synchronized(obj)：JVM 尝试设置偏向锁 → Mark Word 被写入线程 ID + 偏向时间戳 + 末三位变为 101 - 再启另一个线程竞争同一把锁：触发偏向撤销 → Mark Word 恢复为无锁态（001），随后升级为轻量级锁 → 末两位变为 00，高位存指向栈中 Lock Record 的指针
- 若竞争激烈（自旋失败），升级为重量级锁 → 末两位变为 10，高位存指向堆中 Monitor 对象的指针
这些变化全部发生在同一个对象的对象头上，无需修改代码逻辑，仅靠多线程触发即可观察。这就是“变量被保护”的物理基础：不是变量变了，而是它所属对象的头部标记位在动态响应并发行为。
三、为什么不能直接“锁变量”？从内存模型讲清楚
Java 中的局部变量存在栈帧里，生命周期短、线程私有；实例变量和静态变量虽可共享，但 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 查看两个 supposedly “同一个锁”的对象，它们的地址是否一致、Mark Word 是否真被同一 Monitor 关联——这是比日志更底层、更可靠的验证方式。
