偏向锁在高竞争系统中不是优化而是性能放大器，因其撤销需暂停线程、检查栈帧、更新Mark Word并可能升级锁，每次均为微型STW，多对象高频撤销会显著拖慢吞吐、加剧卡顿。
偏向锁在高竞争系统中不是优化，而是性能放大器——频繁撤销会直接拖慢吞吐、引入卡顿、抵消所有锁优化收益。
为什么高竞争下偏向锁撤销成本特别高
偏向锁撤销不是简单改个标志位。它必须确保全局一致性：JVM 要暂停持有偏向锁的线程（哪怕它正在执行普通 Java 代码），检查其栈帧是否还持有该锁，再更新对象头 Mark Word，并可能触发锁升级。这个过程本质是一次微型 STW（Stop-The-World）。
- 每次撤销都涉及线程挂起 + 对象头重写 + 可能的 Monitor 分配
- 若多个线程高频轮番访问同一对象（如共享缓存 key、单例资源锁），撤销/重偏向会成批发生
- 撤销操作无法批量合并，每个对象独立处理，放大开销
如何确认你的系统正被偏向锁撤销拖累
别猜，用 JVM 自带工具看真实撤销事件。关键指标是 BiasedLocking::revoke_and_rebias 和 ObjectSynchronizer::fast_enter 的调用频次，以及 GC 日志中是否出现 biased locking revocation。
- 启动时加参数：
-XX:+PrintBiasedLockingStatistics -XX:+UnlockDiagnosticVMOptions - 运行一段时间后执行：
jcmd或VM.native_memory summary jstat -compiler观察编译停滞是否关联锁撤销 - 更直接：用
jstack抓线程快照，搜索"biased lock revocation"或大量线程卡在ObjectSynchronizer::slow_enter
撤销成本在不同场景下的实际表现差异
撤销开销不是固定值，它高度依赖对象生命周期和竞争模式：
- 短命对象（如方法内 new 出的锁对象）：撤销成本≈创建成本，但若该对象在逃逸分析后被标为“未逃逸”，JIT 可能直接锁消除——此时开启偏向锁反而干扰优化
- 长命共享对象（如 static final Object lock）：一旦被多线程争用，每次新线程首次获取都会触发撤销，且无法降级，累积效应明显
- 调用
Object.hashCode()后的对象：会强制撤销偏向锁（因 hashCode 需要写入 Mark Word），这点极易被忽略
禁用偏向锁前必须验证的两个前提
直接加 -XX:-UseBiasedLocking 很快，但未必正确。先确认两点：
- 你的应用是否真处于“高竞争”而非“误配置”：比如线程池过小导致任务排队，表面看是锁竞争，实则是资源瓶颈
- 是否已有其他锁优化生效：例如 JIT 已对 StringBuffer 做了锁消除，此时偏向锁根本没机会介入，关不关它都没区别
- 测试时务必对比相同负载下的
99% RT和GC pause time，而非只看吞吐——撤销引发的 STW 主要伤害响应尾延迟
真正难处理的不是撤销本身，而是撤销触发条件隐晦：一个看似无害的 hashCode() 调用、一次跨线程的对象传递、甚至 JMX 检查都可能悄悄触发它。监控要落到具体对象实例级别，而不是只看全局统计。
