偏向锁通过单线程重入零开销提升性能，即首次cas记录线程id后，后续仅比对id即可；但需满足未禁用、未调用hashcode/wait/notify、且在延迟启用期内；撤销会stw，现代jdk默认禁用。
Java偏向锁能提高性能，核心在于它把“无竞争场景下的同步开销降为零”——同一线程反复进入同一同步块时，不再需要任何原子操作（如CAS），只做一次线程ID比对即可。
偏向锁加速机制：单线程重入零开销
偏向锁不是靠“加锁更快”，而是靠“根本不加锁”。它的加速逻辑很直接：
- 对象首次被某线程获取锁时，JVM用一次CAS将线程ID写入对象头Mark Word，并标记为“已偏向”（后三位为101）
- 该线程后续每次重入同步块，仅需检查Mark Word中记录的线程ID是否匹配自己，匹配就直接执行临界区代码
- 整个过程不涉及CAS、不触发内存屏障、不修改栈帧锁记录，也没有自旋等待
对比轻量级锁：每次重入都要执行CAS更新锁记录，即使无竞争也带来CPU指令和缓存一致性开销。而偏向锁在典型单线程高频访问场景（如线程私有缓存、局部计数器、初始化后的单例对象访问）下，性能提升显著。
偏向锁触发的前提条件
不是所有对象、所有时机都能进入偏向锁状态。必须同时满足以下四点：
立即学习“Java免费学习笔记（深入）”；
- 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
基本上就这些。理解偏向锁的关键，不是记住流程，而是看清它服务的假设：绝大多数锁，其实只被一个线程用。
