JDK 15起默认禁用偏向锁，因其在多核高并发场景下收益为负：易触发STW撤销、内存开销大、短命对象导致初始化成本超收益，而轻量级锁+自旋已更优。
多核普及让“单线程独占”假设失效
偏向锁的设计前提，是假设某个对象在生命周期内大概率只被一个线程反复访问（比如线程局部缓存、单线程初始化对象）。但现代服务器普遍是 32 核、64 核甚至更多，微服务请求天然分散到不同线程池，synchronized 锁住的对象往往在几十毫秒内就被多个线程轮番访问。此时“偏向”一个线程不仅没收益，反而成了负担。
- JVM 必须为每个对象头预留空间存储偏向线程 ID 和 epoch，增加内存开销
- 一旦发生竞争（哪怕只有一次），就要触发
biased_lock_revocation流程 - 该流程强制所有线程进入
safepoint，造成 STW 暂停——这在高 QPS 场景下直接拉高 P99 延迟
短期对象泛滥使偏向锁初始化成本反超收益
函数计算、Spring WebFlux、Quarkus 等框架大量创建短生命周期对象（如 HttpRequestContext、ResponseWrapper），这些对象存活时间远小于 JVM 默认的偏向锁延时（-XX:BiasedLockingStartupDelay=4000）。结果就是：对象刚被“偏向”，还没来得及被第二次访问，就已被 GC 回收。
- 每次创建对象都要检查是否启用偏向锁、是否在延时期、是否可偏向——这些判断本身就有分支预测开销
- 偏向锁撤销不是原子操作，需遍历目标线程栈 + CAS 更新 Mark Word，比直接走轻量级锁的 CAS 路径更重
- 实测显示，在典型 HTTP API 场景中，开启偏向锁后 GC 日志里频繁出现
Revoking bias of objects记录
轻量级锁 + 自旋优化已足够覆盖多数竞争场景
JDK 15 后默认禁用偏向锁，并不意味着放弃锁优化，而是把资源投向更普适的路径：无锁 → 轻量级锁（CAS + 自旋）→ 重量级锁。这条路径在多核环境下表现更稳定。
-
UseAdaptiveSpinning启用后，JVM 会根据前次自旋成功率动态调整自旋次数，避免空转浪费 CPU - 轻量级锁失败后升级为重量级锁前，仍可借助
ObjectMonitor的队列做公平排队，不依赖全局 safepoint - 对比偏向锁撤销必须等所有线程到达 safepoint，轻量级锁的 CAS 失败只是单次指令失败，无跨线程副作用
禁用后如何验证实际影响
不要只看启动参数是否加了 -XX:-UseBiasedLocking，关键看运行时是否真没触发偏向逻辑。最直接的方式是开启锁统计：
java -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -Xlog:monitoring=debug ...
如果日志中不再出现 Revoking bias 或 Biased locking disabled 类似字样，且 safepoint 平均停留时间下降，则说明偏向锁逻辑已真正退出路径。注意：某些监控 agent（如 Arthas、SkyWalking）若调用 Unsafe.monitorEnter，仍可能意外触发偏向锁相关代码，属于少数例外。
真正容易被忽略的是：即使你没写 synchronized，JDK 内部（比如 java.util.Hashtable、java.text.SimpleDateFormat）仍可能用到，而这些类在 JDK 15+ 中已逐步被并发容器替代——这才是偏向锁退出背后的完整技术闭环。
