JDK 15起默认禁用并废弃偏向锁，因其仅在“单一线程反复进入同步块”场景有效，而现代多核高并发、短命对象、线程池复用等使撤销开销（STW、遍历栈帧）远超收益，JVM转向轻量级锁+自旋、逃逸分析等更普适优化，JDK 21彻底移除。
从 JDK 15 开始，偏向锁被默认禁用并标记为废弃，这不是一次仓促决定，而是基于长期实践反馈和 JVM 同步机制演进的理性调整。
偏向锁的设计初衷本就非常局限
它只在“单一线程反复进入同一同步块”这种极窄场景下有收益。比如早期 Vector、Hashtable 这类粗粒度同步容器，或某些长期由固定线程操作的日志对象。但现代应用中这类模式已大幅减少：
- 并发集合（如 ConcurrentHashMap）普遍替代了同步容器，天然规避无谓锁竞争
- 线程池广泛使用，同一个对象常被不同 worker 轮流访问，导致偏向状态频繁撤销
- 短生命周期对象（如 JSON 解析中间对象、RPC 序列化临时实例）根本来不及稳定持有偏向锁
撤销开销远超预期收益
一旦其他线程尝试获取已被偏向的锁，JVM 必须执行偏向撤销（RevokeBias），这个过程代价很高：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 必须等待所有线程到达全局安全点（Safepoint），引发 STW 延迟尖峰
- 需遍历目标线程栈帧，检查锁记录是否还有效
- 撤销后还要升级为轻量级锁，实际总开销可能高于直接走轻量级锁路径
现代 JVM 已有更高效稳定的替代方案
关闭偏向锁并不等于放弃优化，而是转向更普适、更可控的机制：
立即学习“Java免费学习笔记（深入）”；
- 轻量级锁 + 自旋 在无竞争或轻度竞争下实测开销仅约 2.8 ns/次，且 JIT 可内联判断甚至做锁消除
- 逃逸分析成熟，大量局部同步对象被完全优化掉，根本无需加锁
- 锁粗化与锁消除 等编译期优化，在字节码层面就减少了同步操作数量
JDK 版本演进体现渐进式淘汰逻辑
偏向锁不是突然消失，而是分阶段退出：
- JDK 15：默认关闭（-XX:-UseBiasedLocking），启动时加废弃警告（JEP 374）
- JDK 16：保留参数但默认延迟 4 秒启用，期间所有锁走轻量级路径
- JDK 17（LTS）：UseBiasedLocking 变为只读标志，强行启用会报错
- JDK 21（LTS）：该参数彻底删除，HotSpot 中不再存在偏向锁实现路径
