锁优化之偏向锁撤销：解析 Safepoint 对所有变量线程执行同步的影响

先抛一个核心结论：偏向锁撤销这件事，远比“改个标志位”要复杂。它会强制所有 Ja va 线程停在安全点（Safepoint），形成一次全局同步停顿。这个过程不看锁竞争是否激烈，只看 JVM 是否需要修改对象头并确认线程状态。一旦触发，所有线程都得等，哪怕只有一个对象被撤销，后果也是全局性的。

为什么撤销必须等所有线程进 Safepoint

偏向锁的状态依赖于线程私有的信任机制：原持有线程的栈帧里，可能正隐式跳过 CAS，直接复用偏向 ID。JVM 可不敢在任意时刻强行覆盖 Mark Word，否则会导致该线程后续重入时状态错乱。所以，必须等每个线程自己走到一个可检查的位置——比如方法返回、循环边界、字节码间歇点——再统一暂停、遍历栈帧、判断是否还在同步块中。

• 这个等待过程本身就会卡住所有线程，哪怕只持续几毫秒，放在高 QPS 场景下，也可能引发请求堆积或者超时毛刺——这可不是闹着玩的
• 更棘手的是，如果某个线程卡在长循环里（比如 JIT 认定的计数循环），且未插入 Safepoint 检查，它就无法响应中断。其他线程只能干等，STW 时间可能被拉长到不可接受的程度
• 只能说，撤销操作不是原子指令能完成的，本质上是一次运行时协同调度，类似微型 GC 协调

撤销如何污染整类对象的锁行为

JVM 不是按对象统计撤销次数，而是按 Class 统计。只要同一类的对象被撤销达到阈值，后续所有新实例都会被“连坐”——要么批量重偏向，要么直接禁用偏向锁。

• BiasedLockingBulkRebiasThreshold = 20：某 class 被撤销 20 次后，JVM 尝试给该类所有已偏向对象悄悄换主（升级 epoch）
• BiasedLockingBulkRevokeThreshold = 40：达到 40 次后，对该 class 批量撤销，之后新建的该类对象一出生就是无锁状态
• 这意味着：一个高频创建的类（如 ConcurrentHashMap.Node）只要被多线程争抢几次，整个类的锁策略就被永久改变，影响后续成百上千个实例

hashCode() 是最隐蔽的撤销诱因

很多开发者没意识到，只要对象调用了 hashCode()，JVM 就必须把 Mark Word 中存储的线程 ID 替换为哈希值——这直接导致偏向锁失效，触发一次完整撤销流程。

• 这种撤销完全不经过 synchronized 块，也没有明显锁竞争迹象，却一样要走 Safepoint 流程
• 常见于日志打印、集合 put、JSON 序列化等场景，尤其当对象作为 Map key 或参与 equals/hashCode 合约时
• 这类撤销往往分散、高频、难以归因，但日志里能看到 Safepoint reason 频繁出现 RevokeBias

生产环境更可靠的应对方式

与其花时间调参或排查哪段代码触发了撤销，不如直接关闭偏向锁。现代多核服务中，它的收益早已被 STW 代价彻底抵消。

• JDK 15+ 默认禁用，但 JDK 8/11 仍需显式加参数：-XX:-UseBiasedLocking
• 配合 -XX:+PrintBiasedLockingStatistics 和 -XX:+PrintSafepointStatistics 可验证是否还有撤销发生
• 替代方案优先考虑无锁结构（如 LongAdder）、ThreadLocal 缓存，或确保 synchronized 块极短、避免跨线程共享热点对象