JDK 15起默认禁用并废弃偏向锁，因其在多核高并发场景下撤销开销大（需STW、遍历栈帧）、短命对象导致初始化成本超收益，且轻量级锁+自旋等优化已更高效稳定。
jdk 15 起，偏向锁被默认禁用并标记为废弃，这是 hotspot 同步机制演进的关键转折点。
为什么从 JDK 15 开始禁用偏向锁
偏向锁最初在 JDK 6 引入，目标是优化“单线程反复进入同一同步块”的场景，避免每次加锁都执行 CAS。但随着应用架构变化，其收益大幅缩水：
- 主流集合类（如 HashMap、ConcurrentHashMap）已替代早期同步容器（Hashtable、Vector），天然减少无谓同步
- 线程池普及导致对象常被不同 worker 轮流访问，触发频繁撤销，反而引入 safepoint 延迟尖峰
- 短生命周期对象（如 JSON 解析、RPC 序列化）无法稳定持有偏向状态，初始化 + 撤销开销超过轻量级锁成本
- 偏向锁逻辑深度耦合 JVM 多个子系统，增加维护与重构难度，阻碍同步机制持续优化
JDK 版本中的关键节点
偏向锁支持并非一夜间消失，而是分阶段弱化：
-
JDK 15（2020年9月）：默认关闭（
-XX:-UseBiasedLocking），同时添加废弃警告，JEP 374 正式提出 -
JDK 16（2021年3月）：仍保留参数，但启动延迟（
-XX:BiasedLockingStartupDelay）默认 4 秒，期间所有锁走轻量级路径 -
JDK 17（2021年9月，LTS）：
UseBiasedLocking变为只读标志，强行启用会报Unrecognized VM option，源码中相关逻辑开始移除 - JDK 21（2023年9月，LTS）：该参数彻底删除，HotSpot 中不再存在偏向锁实现路径
禁用后实际运行表现
关闭偏向锁并不等于性能倒退，现代 JVM 已通过其他方式弥补：
- 轻量级锁在单线程无竞争下开销极低（实测约 2.8 ns/次），且 JIT 可内联判断甚至做锁消除
- 逃逸分析成熟，大量局部同步对象被完全优化掉，根本无需锁操作
- 线程池+共享对象类场景（如 Logback Logger、配置 Holder）延迟抖动显著下降，因规避了全局 safepoint 触发的
RevokeBias - 运维更简单：无需再排查
jstack中卡在BiasedLocking::revoke_and_rebias的线程
如何确认你正在运行的环境状态
别依赖文档或启动脚本，直接查 JVM 实际行为：
立即学习“Java免费学习笔记（深入）”；
- 查当前进程：
jinfo -flag UseBiasedLocking <pid>—— JDK 15+ 默认输出false - 查 JVM 支持范围：
java -XX:+PrintFlagsFinal -version | grep UseBiasedLocking—— JDK 17+ 显示manageable = false - 观察运行时痕迹：
-XX:+PrintSafepointStatistics中若高频出现BiasedLockRevocation，说明旧配置仍在生效或存在隐式启用（如 spring-boot-devtools）
