synchronized底层原理：从对象头到锁升级的JVM实现解析

前阵子帮朋友看一个线上问题，服务在高峰期 CPU 直接飙到满，线程 Dump 拉下来一看，一大片线程卡在同一个业务对象的锁上，状态全是 BLOCKED。当时第一反应是“是不是锁粒度太大了”，但顺着字节码和 JVM 日志一路查下去才发现，问题远不止“加锁位置不对”这么简单——synchronized 在现代 JVM 里早就不是我们以为的“又慢又重的老古董”了，它从偏向锁、轻量级锁到重量级锁有一条完整的升级链路，每个阶段的行为、触发条件、性能损耗都不一样。今天这篇文章，我就从 JVM 视角把 synchronized 的底层实现梳理一遍，把对象头、Monitor、锁升级、以及 JMM 带来的内存语义这些硬骨头啃下来。无论你是准备面试还是排查线上锁竞争，这份笔记都值得收藏。

1. synchronized 到底在 JVM 里管了什么

1.1 先搞清楚它解决的是什么问题

Synchronized 并不是一个简单的“某个变量上的标志位”，它是 JVM 通过互斥机制实现线程安全的基础设施。从最朴素的视角看，它解决的是“多线程同时访问一块共享数据”的竞争问题。多线程并发程序里最大的麻烦在于，两个线程同时读写同一个变量，你没法预测最终结果是哪个线程的写入生效。比如账务系统里一个简单的余额变更，如果不用锁保护，就会出现“读到一个旧值、加 100、再写回去”的覆盖场景，这笔账就对了不上。

早年我们学 Java 并发时，老师会告诉你 synchronized 可以保证原子性、可见性、有序性。原子性指的是临界区代码要么全部执行完，要么不执行，线程切换不能把一段临界区拆成两半；可见性指的是一个线程修改了共享变量，另一个线程能立刻读到最新值，而不是读到 CPU 缓存里的旧值；有序性指的是 JVM 和 CPU 在指令重排时不能随意越过锁的边界。这三条，其实都是 JVM 在实现 synchronized 时强制附加的内存语义，并不是语法层面天然保证的。理解了这三条，你才能理解为什么锁的“底层实现”不是一句“加个锁”就能概括的。

这里我习惯用一个生活例子帮助理解：把临界区想象成公司里只有一间的会议室，线程就是来开会的人。synchronized 做的就是“一个人进去时把门锁上，其他人只能在门口排队”。但问题在于，JVM 为了性能，设计了三种“门锁”：如果基本没人抢，就给来开会的人一个专属门禁卡，每次刷卡直接就进；如果有人插队了，就在门口快速抢一下门把手，抢不到再转圈等；如果外面排队的人越来越多，就干脆请一个真正的保安（操作系统）来排队叫号。这个类比基本就对应了偏向锁、轻量级锁和重量级锁。

1.2 从全局看它在 JVM 里的定位

从 JVM 内部实现的角度来看，synchronized 并不仅是一个关键字那么简单，它对应着一整套的运行时协作机制，涉及字节码指令、对象内存布局（特别是对象头 Mark Word）、VM 内部的 ObjectMonitor 数据结构，以及操作系统提供的互斥量（mutex）和条件变量（condition variable）。当你在 Java 源码里写下 synchronized 时，javac 把它编译成字节码；JVM 的 Interpreter 和 C1/C2 编译器在解释执行或即时编译时，再把这些字节码转换成对应的运行时逻辑。

我们需要知道的关键边界是：synchronized 的语义由 JVM 规范定义，但具体实现是 HotSpot 源码里的东西。规范层面只规定了 monitorenter/monitorexit 指令和 ACC_SYNCHRONIZED 标志的行为，但并没有规定必须用偏向锁、轻量级锁这些机制。这些机制是 HotSpot 团队在 JDK 6 以后为性能做的优化，是“实现细节”而非“规范要求”。所以你在读不同版本的 JDK、不同厂商的 JVM 时，锁的具体表现可能会有差异，这也是排查线上问题时要特别注意的地方。

2. 先把字节码摆出来看

2.1 同步代码块与同步方法的字节码差异

要理解 synchronized 的底层实现，第一步不是直接钻源码，而是先用 javap 看一眼它的字节码长什么样。我们来写一段最简单的代码：

java复制public class SyncDemo {

    private final Object lock = new Object();

    public void blockMethod() {
        synchronized (lock) {
            System.out.println("hello");
        }
    }

    public synchronized void syncMethod() {
        System.out.println("world");
    }
}

用 javap -v SyncDemo.class 反编译后，blockMethod() 的字节码大致是：

text复制public void blockMethod();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: aload_1
         1: dup
         2: astore_2
         3: monitorenter
         4: getstatic     #7
         7: ldc           #13
         9: invokevirtual #15
        12: aload_2
        13: monitorexit
        14: goto          22
        17: astore_3
        18: aload_2
        19: monitorexit
        20: aload_3
        21: athrow
        22: return
      Exception table:
         from    to  target type
             4    14    17   any

而 syncMethod() 的字节码里根本没有 monitorenter 和 monitorexit，它只是在方法的 access_flags 上多了 ACC_SYNCHRONIZED 标志：

text复制public synchronized void syncMethod();
    descriptor: ()V
    flags: (0x0029) ACC_PUBLIC, ACC_SYNCHRONIZED

看到了吗？synchronized 修饰同步方法时，锁的获取和释放并不会显式出现在方法体里，而是由 JVM 根据 ACC_SYNCHRONIZED 标志自动完成。当 JVM 执行一个带此标志的方法时，会先把方法所属对象（实例方法）或 Class 对象（静态方法）作为 Monitor 加锁，在方法正常返回或异常抛出时自动释放锁。对于同步代码块，JVM 则必须通过 monitorenter 指令加锁，并通过 monitorexit 指令释放锁——而且看上面的反编译结果，异常表里还注册了一条 catch-all 的处理器，在发生任意异常时再执行一次 monitorexit，确保锁一定能被释放。

2.2 为什么编译器要生成两条 monitorexit

这是一个很容易忽略但极其重要的细节：正常执行路径有一条 monitorexit，异常路径还有一条 monitorexit。很多人以为 try-finally 是写 Java 代码时才用得到的东西，实际上 JVM 编译器在生成同步代码块时，天然就把它翻译成了“正常路径 + finally 式异常路径”的结构。

为什么要这么做？因为锁一旦获取成功，就必须要在退出临界区时释放。假如方法中间抛了异常，没有这个异常路径的 monitorexit，锁就会一直持有不释放，其他线程永远卡在入口。那能不能依赖重量级 Monitor 的自动清理？不能，因为此时可能还停留在偏向锁或轻量级锁阶段，锁信息在栈帧的 Lock Record 里，一直不释放就会造成锁泄漏。所以 monitorexit 必须成对出现，而且异常路径是编译器强制生成的关键保障。这个设计也解释了为什么 synchronized 不需要像 ReentrantLock 那样在 finally 里手动解锁——编译器在字节码层面已经帮你兜底了。

2.3 锁的可重入性从哪里体现

Synchronized 是可重入的，这一点从字节码上看不出来，得从 Monitor 运行时的计数器来看。同一个线程可以多次获取同一把锁，对应到 JVM 内部的 Monitor 上，就是 _recursions 计数器加一；完全退出时减到 0，才真正释放锁。JVM 会先检查当前线程是不是锁的持有者，如果是，只递增计数器，不需要再做任何同步操作。

这样的设计对业务代码非常重要，比如一个 synchronized 方法内部调用同类中另一个 synchronized 方法，如果是不可重入的，就会出现自己锁自己的死锁。JVM 能处理这种情况，正是因为 Monitor 里记录了持有者线程和重入次数。这个知识点在面试里经常被问到，你可以从 Mark Word 和 ObjectMonitor 两个层面分别回答：偏向锁状态下记录的是线程 ID，轻量级锁状态下通过 Lock Record 的 owner 判断，重量级锁状态下则有 _recursions 字段。

3. 对象头：锁信息的物理载体

3.1 对象在内存里的布局

锁信息究竟存在哪？答案是对象的对象头里。HotSpot 中普通对象在堆内存中的布局分为三部分：对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。对象头又包含 Mark Word 和 Klass Pointer（类型指针）。如果是数组对象，对象头里还会多一个数组长度字段。

Mark Word 就是锁实现的核心载体，它有 64 位（64 位 JVM 下）长度，里面存的东西会随着对象状态变化而变化。在无锁状态下，它存储的是对象自身的 hashCode、GC 分代年龄、偏向锁标志位和锁标志位；一旦对象被当作锁使用，JVM 就会把 Mark Word 里的信息改写成线程指针、锁记录指针或者 Monitor 指针。

Klass Pointer 则是指向方法区中类的元数据指针，JVM 通过它来确定对象是哪个类的实例。不过这里有个值得注意的点：如果开启压缩指针，Klass Pointer 只有 32 位，整个对象头在 64 位 JVM 上也就 12 字节，Mark Word 占 8 字节，Klass Pointer 占 4 字节。很多人在用 JOL（Java Object Layout）工具看对象头时，会对“为什么是 12 字节”感到困惑，这里顺便说一下。

3.2 Mark Word 的复用与锁状态标志位

Mark Word 之所以叫“Mark”，就是因为它是一块可以反复解释的内存区域。在 64 位 JVM 上，几个关键状态的位布局大致如下：

注意看，无锁和偏向锁的 biased_lock 标志位有区别，但末尾的 lock 都是 01。这是因为偏向锁本身就是从无锁状态“偏向”过去的，JVM 靠 biased_lock 位来区分两者。

这里有一个非常重要的坑：一旦对象被调用了 Object.hashCode() 并且结果被缓存到 Mark Word 里，这个对象就不能再进入偏向锁状态了。因为偏向锁需要把 54 位都用来存储线程 ID，而 hashCode 也要占 31 位，两者在同一个 Mark Word 里没法共存。在 JDK 8 下你把这个对象作为锁，它只能直接走轻量级锁或重量级锁。这也是为什么很多框架在锁对象设计上建议重写 hashCode() 来规避这个问题，但说实话生产环境不太可能去控制每个对象的 hashCode 调用时机，所以偏向锁的实际适用场景要打折扣。

3.3 Monitor：JVM 内部真正的锁对象

当锁升级到重量级锁时，Mark Word 里存的是一个指向 ObjectMonitor 对象的指针。ObjectMonitor 是 HotSpot 源码 runtime/objectMonitor.hpp 中定义的结构体，它才是重量级锁真正的“锁对象”。简单理解，可以把 ObjectMonitor 看成一个 C++ 层面的管家，负责维护锁的持有者、等待队列、阻塞与唤醒。

ObjectMonitor 中有几个核心字段值得记住：

当一个线程执行 monitorenter 时，JVM 实际上就是对这个 ObjectMonitor 做“进入”操作：如果 _owner 为空，通过 CAS 尝试把它设为当前线程；如果不为空，则判断是否是当前线程持有，是就递增重入次数；否则线程进入 _cxq 或 _EntryList 等待，最终被操作系统挂起。这个过程的代价之所以高，是因为涉及线程上下文切换和用户态到内核态的切换，所以 JVM 才要先用偏向锁和轻量级锁尽量兜住竞争。

4. 锁升级全流程：偏向锁、轻量级锁、重量级锁

4.1 无锁到偏向锁：为了零竞争场景的极致优化

偏向锁的设计初衷非常朴素：在很多真实业务里，一段同步代码绝大多数时间只有一个线程在访问。所谓“偏向”，就是 Mark Word 里记录这个线程的 ID，之后这个线程再来时就什么都不用做，直接进入临界区。它把“加锁/解锁”的成本从原子操作降到了零，因为只需要检查一下线程 ID 是否匹配。

偏向锁的获取过程大致是：当线程第一次访问同步块时，JVM 检查 Mark Word 是否处于可偏向状态（biased_lock=1、lock=01）。如果是，就通过 CAS 把 Mark Word 中的线程 ID 改成当前线程；如果 CAS 失败，说明有竞争，JVM 会尝试撤销偏向锁。

这里的难点在于偏向锁的撤销。当一个偏向锁已经被线程 A 持有，线程 B 来竞争时，JVM 不会在线程 B 中直接改 Mark Word，而是需要等到全局安全点，然后暂停持有偏向锁的线程 A，再判断 A 是否还活着，是否还需要持锁。如果 A 已经退出了同步块，就把 Mark Word 恢复到无锁状态，让 B 重新竞争；如果 A 仍然活跃，就升级为轻量级锁。偏向锁撤销必须经过安全点，这是偏向锁在高竞争下反而会成为性能瓶颈的原因——一次撤销就要全场 STW 一下，顶不住。

4.2 偏向锁的批量重偏向与批量撤销

如果你以为偏向锁只有“偏向/撤销”两种状态，那就小看 JVM 了。HotSpot 还引入了 epoch 字段，用于支持批量重偏向。每个 Class 对象维护一个 epoch 值，每次发生批量撤销时 epoch 加一。当线程尝试获取偏向锁时，如果发现当前对象的 epoch 和 Class 的 epoch 不一样，说明该类发生过批量撤销，那么这个线程可以通过 CAS 重新写入自己的线程 ID，实现“重偏向”。

批量重偏向和批量撤销的阈值可以通过 JVM 参数控制，比如 -XX:BiasedLockingBulkRebiasThreshold 和 -XX:BiasedLockingBulkRevokeThreshold。默认情况下，前者是 20，后者是 40。也就是说，同一个类如果发生 20 次偏向锁撤销，JVM 就会允许批量重偏向；达到 40 次，就会批量撤销该类所有对象的偏向锁，后续新的对象也默认不可偏向。

这个参数在生产环境一般不用调，但理解它的意义能帮助你判断“为什么锁有时会突然变慢”。我遇到过的情况是，某个服务用了线程池 + 自定义锁对象，每个线程池任务都会 new 一个锁对象，偏向锁频繁撤销触发批量撤销，反而导致性能下降。这种情况与其纠结参数，不如直接在高竞争场景下关闭偏向锁，从根上避免。

4.3 轻量级锁：用 CAS 和自旋替代系统调用

当偏向锁被撤销或者一个对象从来没偏向过但存在竞争时，JVM 会尝试使用轻量级锁。它的核心思想是：不立刻让线程阻塞，而是在用户态通过 CAS 自旋来抢锁，避免昂贵的操作系统线程切换。

轻量级锁的获取过程结合了栈帧中的 Lock Record。线程执行同步块时，先在当前线程栈帧中创建一个 Lock Record 空间，然后把对象头 Mark Word 拷贝到 Lock Record。接着通过 CAS 尝试将对象头 Mark Word 修改为指向 Lock Record 的指针。如果修改成功，说明锁获取成功，这个对象就处于轻量级锁状态；如果失败，说明锁已被其他线程占用。此时，如果只有一个其他线程在等待，JVM 会继续进行自旋；如果竞争线程非常多，自旋一段时间后仍然失败，就膨胀为重量级锁。

需要特别强调的是，自旋是轻量级锁保持“轻”的关键，但自旋本身会占 CPU。如果一个锁长时间被持有，自旋的线程会把 CPU 白白烧掉。JDK 6 以后 HotSpot 引入了自适应自旋，JVM 会根据历史命中情况动态调整自旋次数，不再是一个固定值。这也是为什么轻量级锁适合“临界区很小、持锁时间很短、线程竞争不激烈”的场景，在这种场景下它比重量级锁高效得多。

4.4 从轻量级锁膨胀到重量级锁

当自旋无法获取锁，或者已经有线程在 Monitor 上等待时，轻量级锁就会膨胀为重量级锁。膨胀的核心动作是：为对象分配一个 ObjectMonitor，并把 Mark Word 修改为指向 ObjectMonitor 的指针。之后线程的进出都要经过 ObjectMonitor 的 enter/exit 逻辑，竞争失败的线程会调用操作系统提供的同步原语进入阻塞状态，等待被唤醒后重新竞争。

重量级锁的阻塞与唤醒是它的主要开销来源。线程挂起时需要从用户态切到内核态，唤醒时又要切回来，一次切换的成本可能在几十微秒量级。如果临界区代码只执行几微秒，那锁操作本身的切换成本可能比业务代码还高。这也是为什么我们在性能调优时，最希望锁能停留在偏向锁或轻量级锁阶段。

这里整理一下锁升级的整体脉络：

4.5 锁消除与锁粗化：编译器帮你省事

除了锁升级，HotSpot 还有两个编译期优化，分别是锁消除和锁粗化。

锁消除是基于逃逸分析做的。如果一个锁对象根本不会逃逸出当前方法，其他线程不可能访问它，那这个锁就是多余的，JIT 编译器会直接把它去掉。典型例子是方法内部 new 了一个局部对象，并在这个对象上加了锁；由于对象只在线程栈内使用，锁消除后连同步操作都没有。我在看 C2 编译日志时见过这类场景，锁消除确实能带来不小的性能提升。

锁粗化则是把多个相邻的同步块合并成一个。比如循环里反复加锁、解锁，即使没有竞争，重复的 monitorenter/monitorexit 也有成本。JIT 会把整个循环作为一个大的临界区，减少锁操作次数。但要注意，锁粗化可能会让持锁时间变长，在高竞争下反而适得其反，所以 JIT 并不是无脑合并，它会结合逃逸分析和历史竞争情况来做判断。

4.6 JDK 版本演进中的偏向锁

这里想多说一句偏向锁的未来。在 JDK 15 中，JEP 374 将偏向锁标记为废弃，官方给出的原因是偏向锁的维护成本高，而在大量使用线程池和并发容器的现代应用中，锁竞争模型已经发生了很大变化，偏向锁的优势场景越来越少。实际开发中，如果你跑在比较新的 JDK 上，是可以考虑通过 -XX:-UseBiasedLocking 显式关闭偏向锁的，特别是高竞争场景下，至少能避免偏向锁撤销时的安全点开销。

很多线上团队到现在还在用 JDK 8，偏向锁默认开启。如果你在 JDK 8 上做性能调优，建议先通过压测判断锁竞争是否激烈，再决定是否关闭偏向锁。不加分析地抄网上“关闭偏向锁提升性能”的做法，可能在你这种低竞争场景下反而更慢。

5. 从 JMM 看 synchronized 的内存语义

5.1 锁的获取与释放如何影响可见性

很多 Java 开发者把 synchronized 只理解为“互斥”，忽略了它作为内存屏障的作用。实际上，JMM（Java 内存模型）对锁的获取和释放有非常清晰的语义规定：解锁操作 happens-before 后续对同一把锁的加锁操作。这意味着当一个线程释放锁之后，它对共享变量的所有修改都对接下来获取同一把锁的线程可见。

从底层来理解就是：执行 monitorenter 时，JVM 会强制线程将本地工作内存中缓存的相关变量失效，重新从主内存加载；执行 monitorexit 时，JVM 会强制把本地工作内存中修改过的共享变量刷新到主内存。虽然现代 CPU 有自己的多级缓存，JVM 在语义层面已经保证了“加锁后读到的值是最新的”，底层则通过内存屏障指令来实现。

这也是为什么单靠 synchronized 就能保证线程安全——因为被锁保护的临界区里，读到的变量不可能是其他线程修改前的旧值。我在排查并发问题时，经常看到有人只在写操作加锁、读操作不加锁，然后抱怨数据偶尔不一致；其实这正是 JMM 规则不满足的表现，读操作也需要通过锁（或者至少是 volatile）建立 happens-before 关系。

5.2 wait/notify 为什么必须与 synchronized 一起用

这个问题在面试中出现频率极高：为什么 wait() 和 notify() 必须放在 synchronized 块里？答案同样要从 Monitor 说起。Object.wait() 语义是“释放当前持有的 Monitor 并进入等待状态”，Object.notify() 语义是“唤醒一个在该 Monitor 的 WaitSet 中等待的线程”。可以看出，这两个方法天然就是围绕 Monitor 工作的，而 Java 线程只有在持有 Monitor 时才能操作其内部状态。

如果你不在 synchronized 块里调用它们，程序会直接抛出 IllegalMonitorStateException。从另一个角度说，把 wait/notify 放进临界区可以避免“通知丢失”问题。假设两个线程执行顺序是：A 先调用 notify()，B 后调用 wait()，那 B 就会永久等下去。通过在 synchronized 块内保证操作顺序和可见性，可以配合状态变量避免这种竞态条件。

5.3 synchronized 与 volatile 的关系

经常有人问 synchronized 和 volatile 都能保证可见性，是不是可以互相替代？其实不能。volatile 只能保证单个变量的可见性和有序性，不能保证复合操作的原子性。而 synchronized 可以在临界区内把多条操作“打包”成一个不可分割的单元。典型的例子是并发计数器 count++，用 volatile 修饰 count 依然会丢更新；加 synchronized 才能让读-改-写三步整体原子。

从内存语义角度看，synchronized 的加锁与解锁包含了 volatile 写和 volatile 读的内存语义：释放锁相当于 volatile 写，获取锁相当于 volatile 读。所以一份数据如果全部访问都发生在 synchronized 临界区内，就无需再额外声明 volatile，JMM 已经通过锁的 happens-before 规则保证了可见性。这个知识点在面试答“为什么有了 synchronized 还需要 volatile”时非常加分。

6. 实战排查：锁竞争到底卡在哪

6.1 先会用 jstack 看线程状态

线上锁竞争排查最常用的工具就是 jstack。当线程卡在重量级锁上时，线程状态通常是 BLOCKED (on object monitor)；当线程调用了 wait() 后，状态是 WAITING (on object monitor)。它们都指向“某个 Monitor”，区别是 BLOCKED 表示线程在竞争进入，WAITING 表示线程已经进入等待队列，等待被 notify 唤醒。

实际看 jstack 输出时，重点看两个信息：一是当前线程的栈顶，确认它等在哪个业务代码行；二是锁对象的描述行，通常长这样：

text复制- waiting to lock <0x000000076c1e2a90> (a com.example.OrderService)
- locked <0x000000076c1e2a90> (a com.example.OrderService)

locked 表示这个线程持有该对象的 Monitor，waiting to lock 表示这个线程正在等待该对象的 Monitor。从多个线程 Dump 交叉比对，你就能找到“谁持有锁不放”“谁在排队等锁”，进而定位是持锁线程慢还是竞争太激烈。

6.2 用 JFR 定位锁竞争热点

jstack 只能给我们一个瞬间快照，对于偶发性问题，建议用 JDK 自带的 JFR（Java Flight Recorder）来抓取一段时间内的锁竞争情况。开启 JFR 后，在事件列表里关注 Java Monitor Blocked 和 Java Monitor Wait 事件，它们能直接告诉你哪个锁对象被阻塞次数最多、等待时间最长。

有一次排查订单接口变慢，jstack 看不出问题，因为需要拿到锁的线程在很短时间就释放了，但整个服务吞吐被锁竞争严重拖垮。通过 JFR 的 Monitor Blocked 事件，我一眼看到某个订单状态机的 synchronized 方法在高峰期被阻塞了上百万次，平均等待时间有十几毫秒。后来把锁粒度从“订单维度”改成“订单状态维度”，并把无锁状态单独放行，性能直接提升了一个量级。

6.3 死锁检测与避免

重量级锁还有一个老生常谈的问题——死锁。两个线程各自持有一把锁，然后互相等待对方持有的锁，就会形成循环等待。jstack 在 Dump 线程时会在最下方输出检测到的死锁信息，包括死锁涉及的锁对象和线程栈。如果不想等人工 Dump，可以用 jcmd <pid> Thread.print，或者写脚本定时抓取 jstack，再解析死锁关键字。

我个人经验是，死锁问题最有效的解药还是“避免嵌套锁”。如果确实需要多个锁，就保证所有线程以相同的顺序获取锁；或者用 ReentrantLock 的 tryLock 加超时控制。synchronized 本身不支持超时，一旦死锁就只能运维介入，这是它在某些复杂并发场景下的硬伤。

6.4 常见锁问题速查表

7. 高频面试题与深入思考

7.1 面试官最喜欢问的几个点

Synchronized 底层原理是 Java 并发面试的必考项，我梳理了几个反复出现的角度：

synchronized 锁的是什么对象？ 实例方法是当前实例 this，静态方法是当前类的 Class 对象，同步代码块是括号里指定的对象。注意，锁对象必须是非 null 对象，否则 NPE。

synchronized 是可重入的吗？ 是。同一个线程可以多次获取同一把锁，底层通过 Monitor 的重入计数实现，这避免了方法自调用的死锁问题。

偏向锁是不是 JDK 8 默认开启？ 是的。JDK 8 默认 UseBiasedLocking=true。在高竞争场景下可以考虑关闭，但要在压测验证后操作。

锁升级是单向的吗？ 从 Mark Word 维护的锁状态位来看，锁状态可以升级，但一般不会降级。偏向锁可以被撤销回到无锁。轻量级锁膨胀成重量级锁后，通常不会自动降回轻量级锁。不过对象处于无锁状态下，仍然可以重新进入偏向状态。

wait/notify 为什么不加锁会抛异常？ 因为它们是围绕 Monitor 工作的，必须先持有 Monitor，才能操作 WaitSet。

7.2 synchronized 与 ReentrantLock 怎么选

我工作中经常被问到 synchronized 和 ReentrantLock 的选择。从性能看，现代 JDK 中两者差距已经非常小，synchronized 在 JIT 的锁消除、锁粗化加持下，甚至在某些场景更优。ReentrantLock 的核心优势在于功能丰富：

我的建议是：如果你的场景不需要超时和中断，优先用 synchronized。原因很简单，它的语义清晰、自动释放锁、编译器优化更成熟，也更好读。只有当需要公平锁、超时控制、多条件队列时，再考虑 ReentrantLock。

7.3 一道经典的连环追问

面试官通常还会往下追：既然对象头里的 Mark Word 这么小，它怎么能既存 hashCode 又存锁信息呢？这就是我前面讲的复用问题。Mark Word 本身不存储所有信息，它只是一个可解释的位集合。无锁时存 hashCode 和分代年龄，有锁时存线程 ID 或 Monitor 指针。所以不要让锁对象在持锁期间调用 hashCode()，一旦调用了 identity hashCode，偏向锁就无法使用，这也解释了为什么某些对象作为锁时性能不尽如人意。

另一道连环追问是：轻量级锁的 Lock Record 是存在哪里的？答案是当前线程的栈帧里。JVM 在膨胀前先把原 Mark Word 拷贝到 Lock Record，然后 CAS 将 Mark Word 修改为指向 Lock Record 的指针。锁释放时，再用 CAS 把原 Mark Word 换回来。如果 CAS 失败，说明锁已经被膨胀为重量级锁，那么释放时还要唤醒阻塞在 Monitor 上的线程。

8. 我在实践中的几点体会

说句实在话，把 synchronized 底层挖到这一层，并不是为了让你写代码时去手动“操控”锁升级，而是为了遇到问题时能形成准确的直觉判断。比如线上突然发生锁等待飙升，你能立刻在脑子里过一遍：是偏向锁撤销的安全点开销？是轻量级锁自旋烧 CPU？还是重量级锁上下文切换太昂贵？这三类问题的外在表现和排查路径完全不同，如果你只知道“synchronized 是加锁的”，那第一反应可能只是加锁粒度调小，却忽略了元凶是锁消除失败或者 hashCode 干扰。

另一个心得是：不要把“无锁、读写锁”当成灵丹妙药。很多并发场景下，synchronized 反而最简单可靠。我见过不止一个同事把所有 synchronized 换成 ConcurrentHashMap 或原子变量后，代码复杂了，Bug 也多了，最后性能并没有明显提升。锁的开销取决于竞争频率和临界区大小，而不是锁名。先压测，再用 JFR 看数据，最后才决定要不要优化。如果非要给一个总结，我的建议是：默认用 synchronized，它最不容易写错；在明确瓶颈后再考虑 ReentrantLock、读写锁、或者无锁化改造。真正吃透底层的价值，就是让你在“该动”的时候敢动，在“不该动”的时候忍住不动。