偏向锁如何提升性能？详解加速与撤销机制

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《Java偏向锁为何提升性能？详解加速与撤销机制》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

偏向锁通过单线程重入零开销提升性能，即首次CAS记录线程ID后，后续仅比对ID即可；但需满足未禁用、未调用hashCode/wait/notify、且在延迟启用期内；撤销会STW，现代JDK默认禁用。

Java偏向锁能提高性能，核心在于它把“无竞争场景下的同步开销降为零”——同一线程反复进入同一同步块时，不再需要任何原子操作（如CAS），只做一次线程ID比对即可。

偏向锁加速机制：单线程重入零开销

偏向锁不是靠“加锁更快”，而是靠“根本不加锁”。它的加速逻辑很直接：

• 对象首次被某线程获取锁时，JVM用一次CAS将线程ID写入对象头Mark Word，并标记为“已偏向”（后三位为101）
• 该线程后续每次重入同步块，仅需检查Mark Word中记录的线程ID是否匹配自己，匹配就直接执行临界区代码
• 整个过程不涉及CAS、不触发内存屏障、不修改栈帧锁记录，也没有自旋等待

对比轻量级锁：每次重入都要执行CAS更新锁记录，即使无竞争也带来CPU指令和缓存一致性开销。而偏向锁在典型单线程高频访问场景（如线程私有缓存、局部计数器、初始化后的单例对象访问）下，性能提升显著。

偏向锁触发的前提条件

不是所有对象、所有时机都能进入偏向锁状态。必须同时满足以下四点：

• JVM启动时未显式关闭偏向锁（默认开启，可通过-XX:-UseBiasedLocking禁用）
• 对象创建后尚未被调用过hashCode()——因为hashcode会抢占Mark Word空间，导致无法存储线程ID
• 对象未被调用过wait()/notify()——这些方法强制要求重量级锁，会直接禁用偏向
• 当前处于“可偏向”窗口期：偏向锁默认延迟4秒启用（可通过-XX:BiasedLockingStartupDelay=0关闭延迟），新对象在延迟期内仍为无锁状态（0x01）

偏向锁撤销的常见场景

一旦出现以下任一情况，偏向锁就会被撤销（可能升级为轻量级锁）：

• 第二个线程尝试获取同一对象的锁——这是最典型的撤销触发点
• 对象调用了hashCode()方法（Mark Word需腾出空间存哈希值）
• 对象执行了wait()或notify()（必须膨胀至Monitor）
• 发生批量撤销：同一类的对象被撤销偏向锁超40次，JVM判定该类“不适合偏向”，后续新建实例直接不可偏向

注意：撤销操作需在全局安全点（safepoint）进行，会暂停所有应用线程（STW），因此在高并发频繁竞争场景下，反而可能成为性能瓶颈。

实际开发中的取舍建议

偏向锁不是“开箱即用的银弹”，是否启用要结合业务特征判断：

• 适合：Web容器中每个请求线程处理独立对象、批处理中单线程反复操作本地资源、配置类/工具类的同步访问
• 不适合：短生命周期高并发对象（如HTTP连接池、RPC请求对象）、多线程争抢同一锁对象、使用了hashCode或wait/notify的同步逻辑
• 现代JDK（如15+）默认已禁用偏向锁，生产环境若确认无单线程重入优势，建议显式关闭：-XX:-UseBiasedLocking

基本上就这些。理解偏向锁的关键，不是记住流程，而是看清它服务的假设：绝大多数锁，其实只被一个线程用。

本篇关于《偏向锁如何提升性能？详解加速与撤销机制》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！