Java 并发编程里，synchronized 是个怎么都绕不开的话题。面试问八股文，第一波几乎就是“你说说 synchronized 的锁升级过程”，然后等着你背出无锁、偏向锁、轻量级锁、重量级锁这四个名词。但在实际工作中我发现，能背出四个阶段名字的人很多，能讲清楚为什么需要升级、Mark Word 里每个 bit 怎么流转、批量重偏向的阈值是多少、为什么调了 hashCode 就偏向不了的，少之又少。
这篇文章不打算复述教科书。我会从 JVM 底层实现的角度，把锁升级这条路从头捋到尾，讲清楚每个阶段的设计意图、触发条件、切换细节，以及我踩过和见过的那些“看着不对，实际是锁状态导致”的坑。不管你是准备面试，还是写并发代码想搞明白 synchronized 到底干了什么，这篇都比较适合静下心来看完。
1. synchronized 为什么需要“升级”机制
1.1 JDK 1.6 之前的 synchronized 为什么慢
很多人对 synchronized 的印象还停留在“重锁”阶段：每次加锁都要向操作系统申请 mutex，线程获取不到锁就挂起，挂起和恢复涉及用户态到内核态的切换，开销非常大。一个简单的计数器累加，如果每次都走这个流程，吞吐量直接腰斩。这就是 JDK 1.6 之前 synchronized 的真实处境，也是那个年代面试必问“synchronized 和 Lock 哪个性能好”的原因。
但请注意，这个问题的答案早就变了。JDK 1.6 之后，HotSpot 对 synchronized 做了一次大手术，引入了偏向锁、轻量级锁、适应性自旋、锁消除、锁粗化等一系列优化。从此，synchronized 的加锁代价不再是固定的“mutex 一次”，而是根据竞争激烈程度动态调整。一句“synchronized 性能差”挂在嘴边的说法，放到现在是不准确的。
锁升级本质上解决的是一件事：没有竞争的时候，别让我付出锁的成本；有竞争的时候，再根据竞争烈度逐步加码。这就像一家公司，只有一个人的时候不需要开会定流程，两个人配合口头打个招呼就行，等到几十人混战才需要正式会议和邮件审批。JVM 选择锁策略的思路，和现实中的管理逻辑高度一致。
1.2 锁升级的整体设计思路
整个升级路径是单向的：无锁 → 偏向锁 → 轻量级锁 → 重量级锁。JVM 希望用最少成本的方案解决问题，只有当低成本的方案撑不住时，才升级到下一档。
- 无锁态：对象刚创建出来，没有任何线程访问同步块，此时连“锁”的概念都没有，只有对象头里一个普通的 Mark Word。
- 偏向锁：只有一个线程反复进入同步块。JVM 发现这个模式后，直接把线程 ID 记在对象头里，下次这个线程再来，什么都不用做直接进。适用于“同一个线程反复访问同一个锁”的场景。
- 轻量级锁：出现了两个以上线程交替访问同步块，但没有真正同时竞争。此时 CAS 置锁，配合自旋硬扛，尽量不挂起线程。
- 重量级锁：多个线程真正抢同一个锁，自旋已经消耗了大量 CPU，果断交给操作系统管，用互斥量阻塞+唤醒，代价最大但最公平。
这里有两个非常关键的认知。第一，升级是不可逆的，对象一旦进入重量级锁，不会再降回轻量级或偏向锁，这是 HotSpot 为了简单可靠做的取舍。第二，升级不是每次加锁都必须走完全程，比如一个对象创建后第一次加锁，JVM 可以直接让它尝试进入轻量级锁流程，也可能让它直接走偏向锁流程，取决于对象当前状态和 JVM 参数。
2. 读懂对象头，锁升级的基础
2.1 Mark Word：一把锁的状态全在这 8 个字节里
对象头是理解锁升级的根。在 64 位 HotSpot 虚拟机里，一个 Java 对象的内存布局分为三部分：对象头（Mark Word + Class Pointer）、实例数据、对齐填充。其中 Mark Word 固定占 8 字节（64 bit），里面的内容会随着锁状态变化而完全改变。
我整理了一张常见布局表，建议收藏，面试前反复看：
| 锁状态 | Mark Word 存储内容 | 标志位（末尾 bit） |
|---|---|---|
| 无锁 | 对象 hashCode、分代年龄、偏向标记=0 | 01 |
| 偏向锁 | 线程 ID（54 bit）、epoch（2 bit）、分代年龄、偏向标记=1 | 01 |
| 轻量级锁 | 指向栈中 Lock Record 的指针（62 bit） | 00 |
| 重量级锁 | 指向 ObjectMonitor 的指针（62 bit） | 10 |
注意一个细节：无锁和偏向锁的末尾标志位都是 01，要靠中间的 biased_lock 位来区分。biased_lock=0 表示无锁（不可偏向），biased_lock=1 表示可偏向或已偏向。JVM 在判断时，先用最后两位粗分类，再细看中间位，这也是为什么很多人看锁状态源码时容易绕晕的原因。
2.2 hashCode、age、threadId 挤在同一个字段里的冲突
Mark Word 只有 64 bit，要存的信息却很多：identity hashCode（31 bit）、分代年龄 age（4 bit）、偏向线程 ID（54 bit）、epoch（2 bit）、锁标志位（2 bit）。这天然决定了同一时刻只能有一种状态。
最典型的冲突就是 hashCode 和偏向锁。当一个对象的 identity hashCode 被计算过（比如调用了默认的 hashCode() 或 System.identityHashCode()），hashCode 值已经写入 Mark Word 的 31 bit 区域。此时这个对象永远无法进入偏向锁状态，因为如果是偏向锁，这 31 bit 就要让位给偏向线程 ID，hashCode 没地方放。反过来，如果对象已经在偏向锁状态，你再去调 hashCode()，JVM 会先撤销偏向锁，腾出空间写 hashCode。这一点，面试里问“为什么调用 hashCode 后 synchronized 偏向不了”就是这个原因。
理解了 Mark Word 的位布局，再看 JOL 输出的时候你就能直接读出当前对象处于哪一档锁状态。这是每个 Java 工程师都应该掌握的基本功，不需要背眼源码，但布局图一定要印在脑子里。
3. 锁升级的四个阶段与完整切换过程
3.1 无锁 → 偏向锁：单线程场景下的“零成本”加锁
偏向锁是 JVM 团队设计的第一个优化档位，它的核心假设是：很多锁在整个生命周期里，从头到尾只有一个线程访问。这种情况下反复走 CAS、自旋甚至 mutex 都是浪费。
偏向锁的获取流程很简单：对象第一次被某个线程执行 synchronized 块时，Mark Word 已经处于“匿名偏向”状态（biased_lock=1，threadId 为空）。此时 JVM 用一次 CAS 原子操作，把自己的线程 ID 写入 Mark Word。写入成功后，这个锁就“归属”于当前线程了。
之后同一条线程再次进入同一个同步块，JVM 只需要检查 Mark Word 里的偏向线程 ID 是否等于自己。相等就直接执行临界区代码，连 CAS 都不用再发。这就是偏向锁“快”的本质：单线程场景下，加锁就是一次字段比较，比普通代码多不了几纳秒。
这里有个容易忽略的点：synchronized 是可重入的，偏向锁的重入开销更低。因为锁对象和当前线程 ID 匹配后，JVM 不需要在栈上创建额外的锁记录，直接往里走就行。真要验证“这段代码进了几次锁”，只能靠字节码或者 instrumentation，常规手段看不出来。
3.2 偏向锁 → 轻量级锁：出现竞争后的第一道防线
假设线程 A 已经持有了某个对象的偏向锁，线程 B 此时也想抢这个锁。B 发现 Mark Word 里的偏向线程 ID 是 A，不是自己，于是触发偏向锁撤销。
偏向锁撤销不是简单地把线程 ID 换掉，它需要等待全局安全点（SafePoint）。所谓安全点，就是 JVM 暂停所有线程执行，此时堆内存状态是稳定的，可以安全地修改对象头。JVM 把线程 A 停住后，检查 A 是否还处于临界区：
- 如果 A 已经执行完了同步块，偏向锁就作废，Mark Word 恢复成无锁状态，A 和 B 重新公平竞争。
- 如果 A 还在临界区，说明确实有竞争，偏向锁立刻升级为轻量级锁，并把锁的“所有权”交给还在临界区里的 A 继续持有。
这个安全点停顿是有代价的，所以偏向锁的撤销并不便宜。如果一个锁频繁地被多个线程“你用完我用”，偏向锁反而会反复触发撤销，得不偿失。当初 JVM 对偏向锁的定位非常明确：它牺牲撤销时的复杂度，换取绝大多数单线程场景的无条件加速。
升级成轻量级锁之后，线程 B 开始在栈帧中创建一个 Lock Record，里面保存当前希望持有锁的“副本”Mark Word，然后通过 CAS 尝试把对象头里的 Mark Word 替换成指向自己栈帧 Lock Record 的指针。如果 CAS 成功，说明锁抢到了；如果失败，说明对象头里的 Mark Word 指向了别的线程的 Lock Record，锁被占着。这时 B 不会立刻挂起，而是进入自旋——原地空转几纳秒，赌 A 马上就要释放。为什么敢这么赌？因为临界区代码通常很短，挂起线程再唤醒的开销比自旋大得多，等一小会儿是划算的。
3.3 轻量级锁 → 重量级锁：自旋扛不住的时候
自旋不能是无上限的，否则大量线程在空转，CPU 利用率上去了、任务却什么都没干，反而拖垮整个应用。JDK 1.6 引入了适应性自旋：JVM 会根据上一次自旋的成功率动态调整下一次自旋的次数。上次自旋拿到锁了，下次多转几圈；上次白转了，下次少转或者直接放弃。
如果自旋都没等到锁，轻量级锁就正式“膨胀”为重量级锁。这里的关键组件是ObjectMonitor，JVM 内部的监视器对象，它维护着 owner（当前持锁线程）、recursions（重入计数）、EntryList（等待获取锁的线程队列）、WaitSet（执行 wait 后挂起的线程队列）。线程获取不到重量级锁时，会进入 EntryList 排队，由操作系统负责阻塞与唤醒。
重量级锁之所以“重”，就在于阻塞和唤醒线程需要依赖操作系统底层的 mutex 原语，必然发生用户态到内核态的切换。一次切换几十上百纳秒，如果同时有大量线程频繁竞争，这个开销会被无限放大。这也是为什么写了不合理的锁竞争代码时，top 命令里能看到 CPU 的 sys 占比明显升高，因为大量时间耗在内核切换上。
3.4 一条时间线看清完整升级路径
我画个时间线帮助理解，虽然是文字版，但只要跟着走一遍就清楚了：
- 对象刚 new 出来：Mark Word 是无锁状态，末尾标志位 01，偏量标记为 0。
- 线程 A 第一次执行 synchronized 块：JVM 把 A 的线程 ID 写入 Mark Word，进入偏向锁，标志位还是 01，偏量标记变为 1。
- 线程 A 反复进出：每次都只比一次线程 ID，直接通行。
- 线程 B 也想抢：偏向锁在 SafePoint 处撤销，升级为轻量级锁，B 用 CAS + 自旋尝试获取。
- B 自旋到极限也没拿到：锁膨胀为重量级锁，Mark Word 指向 ObjectMonitor，B 阻塞在 EntryList 中。
- A 释放锁，唤醒 B，B 获得锁执行；锁状态已经不会再回到偏向锁。
这套流程最反直觉的地方是：一个锁一旦升到重量级，释放后它也不会变回轻量级或偏向锁。后续所有线程再访问，都直接走重量级锁流程。你在线上看到的“某个对象明明已经没人竞争了，但每次加锁还是慢”，很可能就是锁状态已经永久停留在了高级别档位。
4. 容易被忽视的锁升级细节机制
4.1 批量重偏向与批量撤销：阈值背后的两个数
偏向锁撤销太频繁时，JVM 会判断当前类的对象“不适合继续偏向”，于是引入两个阈值：
- 批量重偏向阈值：默认 20。当某个类的对象偏向撤销次数达到 20 次时，JVM 判定这些对象存在“频繁换手”的倾向，但整体上还存在偏向价值，于是触发批量重偏向。
- 批量撤销阈值：默认 40。当一个类的对象偏向撤销次数达到 40 次，JVM 直接判定该类彻底不适合偏向锁，从此这个类 new 出来的所有对象，直接跳过偏向锁，默认走轻量级锁流程。
批量重偏向我用“标签版本号”来类比：每个类有一个 epoch 值，相当于版本号。正常偏向锁的 threadId 和 epoch 匹配时，说明偏向依然有效。触发批量重偏向后，类的 epoch 加 1，所有对象如果 old_epoch 不等于当前 epoch，那就当作自己没有偏向，可以重新被其他线程偏向。这样就不用一个个去撤销，成本低了很多。
这个机制在排障时很有用。如果你观察到系统里频繁出现“偏向锁撤销”日志，或者性能监控里某个 synchronized 方法的耗时突然升高，很可能是某个类对象的加锁线程频繁切换，触发了批量重偏向甚至禁用偏向。此时可以考虑调整-XX:BiasedLockingBulkRebiasThreshold和-XX:BiasedLockingBulkRevokeThreshold，但更推荐的做法是审视这段代码的锁粒度是不是设计得太粗了。
4.2 hashCode 与 wait/notify 对锁状态的强影响
前面提到 hashCode 会阻止对象进入偏向锁，这里再补全一下。如果你在任何一次加锁前调用过System.identityHashCode(obj)，Mark Word 的 31 bit 已经被 hashCode 占用，JVM 无法再写入偏向线程 ID，所以该对象直接跳过偏向锁，进入轻量级锁流程。反过来，一个偏向锁状态中的对象第一次调用了 hashCode，需要先经过 SafePoint 撤销偏向锁，然后才能写 hashCode 值。
wait/notify 的影响更直接。synchronized 的 wait 和 notify 依赖 ObjectMonitor 的 WaitSet 数据结构，而只有重量级锁才拥有完整的 ObjectMonitor 实例。所以代码里一旦调用了 wait() 或 notify()，JVM 会无条件膨胀锁到重量级，即便当前明明没有竞争。这是很多人在写“锁内 wait 通知模型”时没注意到的隐藏成本，每次 wait 都会让锁永久性地变成重量级。
4.3 JIT 的锁消除与锁粗化：不写锁也能白嫖优化
面试问到锁升级，如果能在最后补一句 JIT 优化，会很加分。锁消除是基于逃逸分析的优化：JVM 发现某个对象的引用根本不会逃逸出当前线程，那加锁毫无意义，编译期直接删除这些加锁指令。比如 StringBuilder 的 append 方法本身有 synchronized，但 JIT 通过逃逸分析识别出局部变量不会逃逸后，就会把锁消掉，这也是为什么局部变量拼字符串用 StringBuilder 性能依旧很高的原因之一。
锁粗化则相反：JVM 发现同一线程对同一对象连续加锁解锁，比如循环里反复 append 同一个 StringBuilder，加锁解锁的缝隙里根本没有其他线程能插进来，于是把加锁范围扩大，合并成一次完整的加锁解锁，省去中间的重复开销。这两个优化是 JIT 在运行时动态做的，不用你手动写，但理解它们能解释很多“为什么我写了加锁代码性能反而没受影响”的疑惑。
5. 实操验证：用 JOL 亲眼看看锁状态
5.1 JOL 环境搭建，5 分钟跑起来
说再多理论，不如自己亲眼看一下对象头。推荐用 OpenJDK 的 JOL（Java Object Layout）工具，Maven 加一行依赖就能用：
<dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol-core</artifactId> <version>0.17</version> </dependency>核心代码非常简单：
import org.openjdk.jol.info.ClassLayout; public class LockStateDemo { public static void main(String[] args) throws Exception { Object obj = new Object(); System.out.println("=== 无锁状态 ==="); System.out.println(ClassLayout.parseInstance(obj).toPrintable()); synchronized (obj) { System.out.println("=== synchronized 持有中 ==="); System.out.println(ClassLayout.parseInstance(obj).toPrintable()); } } }这段代码打印出来的 Mark Word 十六进制值中，看末尾两位就能区分锁状态：01 是无锁或偏向，00 是轻量级，10 是重量级。再配合偏置标记位，基本一眼就能读出状态。注意运行 JOL 时要用-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0让偏向锁立即生效，否则默认要等 JVM 启动 4 秒后才开启，你第一眼看到的永远是轻量级锁。
5.2 三种状态的实测结果解读
我拿自己的测试环境跑过一遍，打印结果大致长这样（十六进制值因 JVM 版本略有差异，但状态判断逻辑一致）：
- 新建对象后，Mark Word 末尾是
01，biased_lock 位为 0，输出标注为non-biasable，说明此刻是无锁状态。 - 单线程持有锁并开启偏向锁时，Mark Word 会变成偏向锁布局，输出标注里能看到
biased: thread以及具体的线程 ID 偏移量。 - 两个线程交替抢锁时，Mark Word 的末尾变成
00，输出标注为thin lock，这是轻量级锁的典型特征，锁的状态变成了指向线程栈中 Lock Record 的指针。 - 如果真的调用一次 wait()，再看对象头，Mark Word 末尾会变成
10，输出为fat lock，从此这个锁就是重量级锁，再也不会回退。
整个测试做下来，最大的感受是“眼见为实”。以前看八股文里的锁升级流程，总觉得抽象，看完 JOL 输出之后，Mark Word 里的每一位变化全部落地了。建议读者把这段代码直接复制到自己项目里跑一遍，多花 5 分钟，事半功倍。
5.3 这个实验里容易踩的坑
JOL 验证有几个细节，第一次做很容易翻车。
第一，JVM 参数没配对。默认偏向锁延迟 4 秒启动，你如果直接跑上面代码，看到的基本都是轻量级锁和无锁，以为偏向锁不存在。必须在启动参数里加上-XX:BiasedLockingStartupDelay=0关闭延迟。
第二，JDK 15 之后偏向锁默认关闭。如果你用的是 JDK 17 或更高版本跑实验，需要显式加-XX:+UseBiasedLocking，否则进入的就是轻量级锁而非偏向锁。
第三，打印偏向前别先调用 hashCode。实验前如果调用了obj.hashCode()或System.identityHashCode(obj)，这个对象就再也不能偏向，实验结果直接失效。我的建议是“读完 Mark Word 之后，再做其他操作”，顺序错了结论就反了。
6. 高频面试问答与实战避坑速查
6.1 面试官常问的 7 个判定题
我把常被追问的细节整理成了表格，每一条都是在面试里真实出现过的：
| 问题 | 一句话结论 | 展开说明 |
|---|---|---|
| 锁升级是单向的吗？ | 是，单向不可逆 | 一旦升到重量级锁不会回退；释放锁后对象头回到无锁，但下一次加锁不会再走偏向 |
| 偏向锁适合什么场景？ | 单线程反复进入锁 | 多线程交替进来时会反复撤销，成本比收益高 |
| 自旋锁是重量级锁的一部分吗？ | 不是，属于轻量级锁阶段 | 轻量级锁获取失败先自旋，扛不住才膨胀成重量级 |
| hashCode 对偏向锁有什么影响？ | 调用过 hashCode 就无法偏向 | Mark Word 空间冲突，biased_lock 置 0 |
| wait/notify 一定会升级重量级锁吗？ | 会 | wait/notify 依赖 ObjectMonitor，只有重量级锁有 WaitSet |
| 偏向锁重入要 CAS 吗？ | 不要 | 直接比对线程 ID，相等就是自己的偏向锁 |
| 重量级锁为什么慢？ | 涉及用户态内核态切换 | 阻塞唤醒由操作系统 mutex 完成，切换开销远大于 CAS |
这七条如果都能脱口而出，synchronized 锁升级这一块就基本过关了。我面试时看到候选人能主动把“hashCode 冲突”和“wait 强制膨胀”这两个冷门点说出来，无论最终结论如何，基础功底都是明显达标的。
6.2 我在实际项目里见过的三个真实问题
第一个问题是锁状态监控误判。有同事用 JOL 打印线上对象的状态，发现一堆对象处于重量级锁状态，直接得出“锁竞争严重”的结论。但实际压测数据显示线程阻塞率几乎为零。后来排查发现，这些对象在某个初始化流程里被调过 wait()，锁从此永久变成重量级，后续即使单线程访问也回不去。所以看到重量级锁，不一定等于当前有竞争，要结合线程 Dump 一起看。
第二个问题是偏向锁参数被无脑调低。有团队为了“避免偏向锁撤销开销”，把BiasedLockingBulkRevokeThreshold调到 1，结果 JVM 启动后大量类直接被禁用偏向锁。线程反复进入同一个锁时，每次都要走完整的加锁和解锁流程，性能反而比默认参数低了 5% 左右。调整这类参数前，先用 JFR 或 Async Profiler 确认偏向锁撤销确实是热点，不要凭感觉优化。
第三个问题是对 synchronized 的偏见。直到现在还有人在并发场景里“逢锁必用 Lock”，理由是 synchronized 慢。JDK 18 之后，synchronized 在无竞争时的开销已经非常低，偏向锁配合 JIT 优化后，绝大多数场景和 ReentrantLock 已经没有数量级差距。我对团队的建议一直是：能用 synchronized 解决的并发问题，优先 synchronized；需要超时、可中断、多个条件队列，再上 ReentrantLock。锁升级机制的存在，就是为了让 synchronized 能在大多数场景下自己“瘦身”，别把它当老古董。
回到锁升级本身，我个人的体会是：真正影响系统性能的从来不是锁机制本身，而是临界区太长、锁粒度太大。锁升级在做的就是一件事——让你的同步代码“在该便宜的时候便宜，在该昂贵的时候昂贵”。理解这一点，比背下四个阶段的名字有用得多。面试官追问细节时，你如果能从 Mark Word 的位布局讲到批量重偏向阈值，再补一句“Java 15 之后偏向锁默认关闭，因为现代框架和容器环境下偏向锁收益下降”，这一题就基本稳了。
最后再送一个排查技巧：线上如果怀疑锁竞争开销大，先别急着改代码，用jcmd <pid> Thread.print -l看看线程到底阻塞在哪个锁上，再配合 JOL 看对象头到底是哪一档锁状态。两步定位下来，问题往往出在锁竞争激烈导致的重量级阻塞，而不是 synchronized 本身。
