java 15起默认禁用偏向锁，因其在多核高并发场景下撤销开销大（需stw、遍历栈帧）、短命对象导致初始化成本超收益，而轻量级锁+自旋等优化已更高效稳定。
Java 15 起默认禁用偏向锁，不是因为技术“坏了”，而是它在现代应用环境中收益变小、成本变高，不再值得保留。
多核高并发让“单线程偏好”失效
偏向锁的设计前提是：某个对象大概率长期被同一个线程反复加锁。但如今微服务、线程池、连接复用等架构下，一个锁常在毫秒级内被多个 worker 线程轮番访问。刚偏向 A 线程，B 线程就来争抢——结果不是省开销，而是立刻触发撤销流程。
- 主流集合类（如 ConcurrentHashMap）已替代 Hashtable/Vector，天然减少无谓同步
- 短生命周期对象（如 JSON 解析中间对象、HTTP 请求上下文）存活时间远短于偏向锁默认延迟（4 秒），刚初始化就被 GC，完全没机会复用
- 每次对象创建都要判断是否可偏向，分支预测开销虽小，但高频场景下积少成多
撤销操作代价远超预期
一旦发生竞争，JVM 必须执行撤销（revocation），这不是简单标记，而是一次隐式 STW：
- 强制所有线程进入 Safepoint
- 挂起持有偏向锁的线程
- 遍历其栈帧，确认是否仍在同步块内
- CAS 更新对象头 Mark Word
这个过程在高 QPS 场景中可能引发毫秒级停顿，SPECjbb2015 测试显示，撤销耗时可占同步总开销 20% 以上，直接拉高 P99 延迟。
轻量级锁路径已足够高效稳定
现代 CPU 的 CAS 指令延迟大幅下降，加上 JVM 的自适应自旋、锁消除、锁粗化等优化，使得“无锁 → 轻量级锁 → 重量级锁”这条路径更简洁、更普适：
- 不依赖线程 ID 和 epoch，无状态维护负担
- 没有撤销路径，锁升级逻辑清晰，不易出竞态 Bug
- 实测表明：禁用偏向锁后，99% 延迟下降 5%–10%，吞吐量无损
JVM 工程维护压力显著降低
偏向锁逻辑深度耦合 GC、线程调度、栈遍历等多个子系统，占 HotSpot 约 2% 的代码量，调试和重构难度高。JDK 17 起该参数变为只读，JDK 21 彻底删除相关实现——这不是功能倒退，而是把资源聚焦在更通用、更可控的优化路径上。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
