偏向锁在jdk高版本中被默认废弃，因其依赖的“单线程长期持锁”假设在多核高并发、短命对象泛滥的现代环境中已不成立，撤销触发stw、内存开销大、初始化成本超收益，故转向更稳健的轻量级锁路径。
Java 偏向锁在 JDK 高版本中默认被废弃或关闭，核心原因不是它“设计错了”，而是它所依赖的运行假设——单线程长期持有对象——在现代应用环境中已基本不成立。它从一种轻量优化，变成了隐性性能负担和维护累赘。
多核高并发让“偏向”失去前提
偏向锁诞生于单核或双核时代，针对的是“一个对象几乎总被同一个线程反复访问”的场景（如单例初始化、线程局部缓存）。但如今服务器普遍是 32 核、64 核起步，微服务请求由不同线程池分发，一个 HTTP 请求创建的 Request 对象可能几十毫秒内就被线程 A、B、C 轮番争抢。此时“偏向”某个线程不仅没省开销，反而成为竞争触发点：
- 只要第二个线程尝试获取已被偏向的锁，就必须执行撤销流程
- 撤销失败或频繁发生，会直接拉高 P99 延迟，影响接口稳定性
- 线程池复用机制天然打破“单线程长期持有”的前提
撤销过程强制全局停顿（STW），代价远超收益
偏向锁撤销不是一次简单 CAS 就能完成的事，它必须走完整个 JVM 全局协调路径：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 暂停所有 Java 线程，等待它们到达 safepoint
- 遍历目标线程栈，定位并修复所有相关锁记录
- CAS 更新对象头 Mark Word，转为轻量级锁状态
这个过程无法局部化，每次撤销都可能引发 STW 尖峰。在高 QPS 场景下，Revoking bias of objects 在 GC 日志中高频出现，说明撤销已是常态而非例外。
短命对象泛滥，初始化成本反超收益
Spring WebFlux、Quarkus、函数计算等框架大量创建短暂存活的对象（如 DTO、Wrapper、Context），很多对象生命周期远小于 JVM 默认的偏向锁延迟（-XX:BiasedLockingStartupDelay=4000ms）：
- 对象刚被写入线程 ID 和 epoch，还没来得及第二次访问，就已被 GC 回收
- 每个对象头需额外预留 62 位空间存 threadID 和 epoch，增加内存压力与 GC 负担
- 每次新建对象都要判断是否启用、是否在延时期、是否可偏向——这些分支判断干扰 CPU 流水线
轻量级锁 + 自适应自旋已更稳健高效
禁用偏向锁不等于放弃优化，而是把资源投向更普适、更可控的路径：
- 无锁 → 轻量级锁（CAS + 自旋）→ 重量级锁，这条主路径在多核环境下表现更稳定
- UseAdaptiveSpinning 启用后，JVM 可根据前次自旋成功率动态调优次数，避免空转浪费 CPU
- 轻量级锁失败只是单次 CAS 失败，无跨线程副作用；升级为重量级锁前仍可通过 ObjectMonitor 队列公平排队，不依赖全局 safepoint
- JIT 编译器成熟后，还能对逃逸分析识别出的局部同步对象做锁消除，根本绕过锁逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
