偏向锁的设计初衷是为单线程场景减负，通过记录线程id到对象头避免cas开销；但多核高并发下“单线程长期持有”假设失效，撤销引发stw、内存开销大、短命对象使初始化成本超收益，jdk 15起默认禁用并转向轻量级锁路径。
偏向锁的设计初衷：为单线程场景减负
JDK 1.6 引入偏向锁，核心目标很明确：**消除无竞争下的同步开销**。它假设一个对象在生命周期内大概率只被同一个线程反复访问（比如单例初始化、线程局部缓存）。此时，首次获取锁时记录线程 ID 到对象头 Mark Word；后续该线程再进入同步块，只需比对线程 ID 和标志位，无需 CAS 或系统调用——连原子操作都省了。
这种“懒加载式”的锁持有机制，在单线程或低并发环境下确实有效。例如 Spring 容器启动阶段对 BeanFactory 的单次初始化，或某些批处理任务中线程复用同一资源的场景，都能显著降低锁获取延迟。
硬件与应用模式变化让前提失效
现代服务器普遍是 32 核、64 核甚至更高，微服务架构下请求天然分散到不同线程池，synchronized 锁住的对象往往在几十毫秒内就被多个线程轮番访问。原来“单线程长期持有”的假设不再成立。
- 多核高并发下，“偏向”一个线程反而成了负担：一旦有第二个线程尝试加锁，就必须触发偏向锁撤销
- 撤销过程强制所有线程进入 safepoint，造成 STW 暂停——这在高 QPS 场景下直接拉高 P99 延迟
- 短生命周期对象泛滥（如 WebFlux 中的 Request/Response 封装类），存活时间远小于默认 4 秒延时，刚被偏向就回收，初始化成本反超收益
运行时开销与维护成本持续走高
偏向锁不是免费的优化，它带来三类隐性代价：
- 内存膨胀：每个对象头需预留空间存储 threadID 和 epoch，64 位 JVM 下额外占用 54+2+1+4+1=62 位，增加 GC 压力
- 分支预测开销：每次创建对象都要判断是否启用偏向锁、是否在延时期、是否可偏向，这些条件跳转影响 CPU 流水线效率
- 撤销路径复杂：需遍历目标线程栈、修复锁记录、CAS 更新 Mark Word，比轻量级锁失败时的单次 CAS 更重
实测显示，在典型 HTTP API 场景中开启偏向锁后，GC 日志频繁出现 Revoking bias of objects 记录，说明撤销动作已成常态而非例外。
JDK 15 起转向更普适的轻量级锁路径
禁用偏向锁不等于放弃优化，而是把资源投向更稳健的路径：无锁 → 轻量级锁（CAS + 自旋）→ 重量级锁。
- UseAdaptiveSpinning 启用后，JVM 可根据前次自旋成功率动态调整次数，避免空转浪费 CPU
- 轻量级锁失败升级为重量级锁前，仍可通过 ObjectMonitor 队列做公平排队，不依赖全局 safepoint
- CAS 失败只是单次指令失败，无跨线程副作用；而偏向锁撤销必须等所有线程到达 safepoint，影响面更大
JDK 15 默认禁用（-XX:-UseBiasedLocking），JDK 17 彻底移除相关逻辑。验证是否真正禁用，不能只看启动参数，应观察运行时是否还有 safepoint 触发的撤销日志。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
