JDK15偏向锁废弃，多核性能影响解析

JDK 15 默认废弃偏向锁，直面多核时代高并发场景下的性能陷阱：在32核+服务器和微服务分散请求的现实下，“单线程独占”的假设早已失效，偏向锁不仅无法带来收益，反而因频繁触发STW撤销、增加对象头内存开销、加重短命对象初始化负担而拖累P99延迟；取而代之的是更普适稳健的轻量级锁+自旋优化路径，配合自适应自旋与无全局safepoint依赖的升级机制，在真实HTTP API等典型负载中展现出更优的吞吐与响应稳定性——这不仅是锁机制的精简，更是JVM面向现代硬件与云原生架构的一次关键进化。

多核普及让“单线程独占”假设失效

偏向锁的设计前提，是假设某个对象在生命周期内大概率只被一个线程反复访问（比如线程局部缓存、单线程初始化对象）。但现代服务器普遍是 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+ 中已逐步被并发容器替代——这才是偏向锁退出背后的完整技术闭环。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~