Java 中偏向锁在多线程竞争时的撤销机制如何运作

偏向锁在多线程竞争时，并不会像我们想象的那样“自动释放”或者“主动退出”。实际上，它是被被动撤销的——这个过程不由持有锁的线程自己发起，而是当另一个线程想要获取锁时，JVM检测到竞争后，立刻“踩一脚刹车”，强制启动清理操作。

撤销发生的准确时机

这里有个关键点：只要另一个线程进入 synchronized 块，并发现对象头中记录的偏向线程 ID 跟自己对不上，撤销就已经触发了。注意，不需要这个竞争线程真的成功拿到锁——哪怕它CAS操作失败了，撤销也一样会进行。

不过，撤销并不会立即执行。JVM必须等到所有线程都运行到一个安全点（safepoint），才能开始做这个清理工作。更有意思的是，就算持有偏向锁的线程早就退出了同步块，JVM也得在安全点把它挂起来，检查完它的栈帧，再完成撤销。也就是说，哪怕没人在用，该走的流程一步都不会少。

撤销过程的关键步骤

听起来复杂，但撤销本质上是一次带状态迁移的原子操作，具体分为几步：

• 首先，通过对象头里的线程 ID，找到那个持有偏向锁的线程；
• 然后，遍历它的线程栈帧，确认它到底还在不在执行原来的同步块里；
• 接着，根据检查结果走两条路：如果持有线程已经退出了同步块，就把对象头恢复成无锁状态（标志位 01）；如果它还在里面，那就升级成轻量级锁（标志位 00，同时写入指向栈中锁记录的指针）；
• 对象头更新完成后，后面再有人来加锁，就直接走轻量级锁的逻辑了——CAS加自旋。

批量撤销与阈值控制

单次撤销的开销其实不大，但万一遇到高频竞争，频繁触发安全点停顿就麻烦了。为此，JVM设计了一套批量机制：

• 当同一类对象的偏向锁被撤销达到40次（默认值 BiasedLockingBulkRevokeThreshold=40），JVM会直接禁用该类所有新实例的偏向锁；
• 同时，已经存在的偏向对象会被批量撤销，之后新创建的对象，默认就是无锁或轻量级锁状态；
• 这个机制是不可逆的——除非重启JVM，或者通过类卸载配合显式重置类元数据（比如用 -XX:BiasedLockingStartupDelay=0），否则回不来。

哪些操作会强制触发撤销

除了线程竞争，还有几种行为也会导致偏向锁直接失效：

• 调用对象的 hashCode()——这会直接覆盖 Mark Word 里的线程 ID 字段；
• 调用 wait() 或 notify()——这类操作必须升级为重量级锁，连带撤销偏向状态；
• 显式关闭偏向锁，比如加上 -XX:-UseBiasedLocking（JDK 15 之后默认就是关闭的）。