怎么通过 JVM **偏向锁（Biased Locking）**撤销代价分析理解现代多核下的同步优化

怎么通过 JVM 偏向锁（Biased Locking）撤销代价分析理解现代多核下的同步优化

关于偏向锁，在现代多核 JVM 的语境下，讨论的焦点早已不是“要不要用”，而是“它根本不存在了”。从 JDK 15 起默认禁用，到 JDK 20 彻底删除相关代码，再到 JDK 21+ 的 HotSpot 中 BiasedLocking 逻辑被完全移除，这条技术路线已经画上了句号。因此，今天我们分析其“撤销代价”，本质是为了理解 JVM 为何最终选择放弃它。

JDK 15+ 默认禁用偏向锁，JDK 17+ 彻底移除；其撤销需全局安全点（STW），导致毫秒级延迟，故现代 JVM 直接走无锁→轻量级锁→重量级锁路径，重点优化自适应自旋。

为什么一次 biased lock revoke 会触发 STW？

关键在于，撤销偏向锁并非一个可以随时进行的轻量操作。它需要修改所有线程共享的锁对象头（Mark Word），更棘手的是，还可能涉及清理各个线程栈中已经缓存的偏向状态。为了保证数据一致性，JVM 必须等待所有 Ja va 线程都到达一个安全点（Safepoint）才能动手——这就不可避免地引发了全局暂停（Stop-The-World）。换句话说，哪怕你只想撤销一个锁，只要有一个线程还没“停稳”，所有线程都得等着。

• 常见错误现象：在高并发同步块密集的场景下，查看 GC 日志或 jstack -l 输出，可能会发现 VMThread 长时间卡在 safepoint。
• 实际影响：一次撤销操作本身的平均耗时可能只有几十微秒，但 STW 的等待时间取决于那个最慢的线程。这个时间可能被拉长到毫秒级，对于金融交易、实时推荐这类延迟敏感的服务而言，这是不可接受的。
• 注意一个细节：当 synchronized(obj) 触发撤销时，JVM 统计的是 obj.getClass() 这个类维度的撤销次数，而非单个对象。因此，后续的批量重偏向或批量撤销决策，都是按 Class 维度来聚合处理的。

BiasedLockingBulkRebiasThreshold 和 BiasedLockingBulkRevokeThreshold 怎么影响行为？

这两个参数仅在偏向锁被显式启用（即通过 -XX:+UseBiasedLocking 开启）时才会生效，它们共同控制了 JVM 对某个类下所有偏向锁对象的“抢救策略”：

• BiasedLockingBulkRebiasThreshold = 20：当同一个类的对象发生了 20 次撤销后，JVM 会尝试“批量重偏向”。具体做法是给这个类的 epoch 值加 1，然后“悄悄地”将所有已偏向对象的线程 ID 替换成当前正在竞争的线程，这个过程可以避免再次进入 STW。
• BiasedLockingBulkRevokeThreshold = 40：如果撤销次数达到 40 次，JVM 就会认为这个类的对象不适合再用偏向锁了。它会直接批量撤销该类所有对象的偏向状态，并且后续为该类新建的对象也不会再启用偏向锁。
• 关键区别：只有对类对象加锁（即 synchronized(obj.getClass())）才会直接进入这个类级别的统计路径。而普通的 synchronized(obj) 虽然只影响单个对象实例，但其触发的撤销行为，最终仍需走上述类级别的决策路径。

JDK 15+ 默认禁用后，synchronized 实际走哪条路径？

移除了偏向锁这个环节后，synchronized 的锁升级路径变得清晰而直接：无锁 → 轻量级锁（thin lock）→ 重量级锁。现代 JVM（尤其是 JDK 17 到 21 版本）的优化重心，已经转移到了轻量级锁的自适应自旋上：

• 轻量级锁通过 CAS 操作尝试获取锁，如果失败，它不会立即让线程阻塞陷入内核态，而是根据该锁历史上的竞争情况，智能地决定自旋等待的次数（adaptive spinning）。
• 自旋操作完全在用户态完成，避免了昂贵的操作系统内核切换。结合现代 CPU 高效的 CAS 指令和分支预测能力，对于短临界区的代码，这种策略比“为了省一次初始 CAS 操作，却可能换来一次 STW”的偏向锁方案要划算得多。
• 实测数据也支持这一点：在 8 核以上的环境中，对于平均持有时间很短的锁，无偏向锁的路径往往能提供更平滑、可预测的性能表现。
• 一个配置提醒：在 JDK 21+ 版本中，如果尝试使用 -XX:+UseBiasedLocking 参数，只会收到一个警告并被忽略；从 JDK 20 开始，这个参数就已经完全失效了。

最后，需要理解的是，偏向锁的消亡并非因为它是一个“错误”的设计，而是它所基于的核心假设——锁会被单个线程长期持有——与当今主流的应用模式（大量短生命周期对象被多线程交替访问）产生了根本性的错位。分析其撤销代价，最终是为了让我们看清一个趋势：现代 JVM 锁优化的重心，早已从“节省一次原子操作”的微观博弈，全面转向了“严格控制 STW、压平延迟毛刺”的宏观系统稳定性保障。