偏向锁已从JDK 15起默认禁用、标记废弃，JDK 17+彻底移除；其退场是因多线程争用场景增多导致撤销开销剧增，而无锁→轻量级锁路径更普适高效。
偏向锁的生命周期，本质是jvm锁优化策略随硬件与应用演进的一次理性退场：它不是“失败”，而是从“有用但过时”走向“维护成本远超收益”的自然结果。
引入阶段（JDK 6）：为单线程场景降本增效
2004年前后，多核CPU尚未普及，服务器普遍是单核或双核，大量Java应用（如早期Web容器、单例初始化、配置加载）存在“一个对象长期被同一线程反复加锁”的典型模式。此时每次synchronized都走CAS，开销明显。偏向锁应运而生——首次获取锁时记录线程ID，后续同线程进入直接比对ID，跳过原子操作。实测在Hashtable、Vector等老集合高频访问场景下，吞吐提升显著。
衰落阶段（JDK 8–14）：假设崩塌，撤销成瓶颈
微服务、异步框架（WebFlux/Quarkus）、连接池和RPC泛滥后，“单线程长持有”变成小概率事件。一个锁常在毫秒级内被多个线程轮番争用：
- 刚被Thread-1偏向，Thread-2一来就触发撤销（revocation）
- 撤销需全局安全点（Safepoint），挂起所有线程，遍历栈帧确认锁状态，再CAS更新Mark Word
- 一次撤销常带来0.5–3ms停顿，在高QPS服务中成为P99延迟尖峰主因
- 每个对象头额外占用存储空间，短命对象（如JSON解析临时对象）刚被偏向就回收，纯属浪费
弃用与移除阶段（JDK 15起）：默认禁用→标记废弃→逻辑删除
JDK 15（2020年发布）通过JEP 374正式行动：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 默认禁用：等价于启动时自动添加-XX:-UseBiasedLocking
- 参数废弃：-XX:BiasedLockingStartupDelay等参数被标为deprecated，文档明确提示“未来将移除”
- JDK 17+彻底删除：HotSpot源码中相关逻辑被清空，强行加-XX:+UseBiasedLocking会报Unrecognized VM option
- 替代路径更轻量：无锁 → 轻量级锁（CAS+自适应自旋）→ 重量级锁，全程不依赖线程ID、无撤销路径、不强制STW
为什么说这不是“倒退”，而是进化？
禁用偏向锁后，SPECjbb2015等基准测试显示99%延迟下降5%–10%，吞吐未损；Spring Boot服务压测中，Safepoint次数锐减，RevokeBias日志消失。JVM把资源转向更普适的优化：锁消除、锁粗化、自旋策略调优——这些不挑场景，多核、高并发、短对象全适配。偏向锁完成了它的历史使命，安静退场。
立即学习“Java免费学习笔记（深入）”；
