偏向锁在无竞争下通过首次CAS写入线程ID、后续仅读取比对实现零成本重入，耗时约1 cycle，远低于轻量级锁的20–50 cycles；但依赖对象未调用hashCode/wait/notify、JVM未禁用等条件，且因撤销需全局safepoint、维护成本高，JDK 15起默认关闭，JDK 17+彻底移除。

偏向锁在无竞争场景下确实能带来显著的性能红利，核心在于它把“获取锁”这个动作从一次原子操作降级为一次普通内存读取。

偏向锁如何实现零成本重入

当一个线程首次获得某个对象的锁时，JVM会通过一次CAS将该线程ID写入对象头的Mark Word，并标记锁状态为“偏向”。此后，只要还是这个线程再次进入同步块：

• 只需读取Mark Word中的线程ID字段，与当前线程ID比对
• 匹配成功即直接进入临界区，不触发任何同步指令（如monitorenter）
• 全程不涉及CPU缓存行争用、不修改内存屏障、不触发JVM safepoint检查

对比轻量级锁的真实开销差异

轻量级锁每次加锁都需执行一次CAS操作，即使无竞争也绕不开原子指令的硬件代价。而偏向锁只在首次启用时有一次CAS，后续全是纯读操作：

• 偏向锁重入：约1个cycle（一次L1缓存命中读）
• 轻量级锁重入：通常20–50 cycles（含CAS失败路径、栈帧锁记录分配等）
• 基准测试显示，无竞争下偏向锁单次操作耗时可低至0.01纳秒，仅为轻量级锁的1/5

红利兑现的前提条件

这种红利不是自动生效的，依赖几个关键事实同时成立：

• 对象未被调用过hashCode()——否则Mark Word需存储哈希值，无法保留线程ID
• 对象未调用过wait()或notify()——这些方法强制升级为重量级锁
• JVM未在启动后禁用偏向锁（默认开启，但JDK 15+已默认关闭）
• 线程未发生长时间停顿或GC导致的safepoint，否则可能触发批量撤销

为什么现代JDK逐步弃用它

红利虽真实，但维护成本越来越高：

• 撤销偏向锁必须进入全局safepoint，暂停所有应用线程，延迟不可控
• 多核CPU上原子指令变快，自旋锁（轻量级锁）的相对优势缩小
• 偏向锁逻辑深度耦合JVM同步子系统，增加HotSpot代码复杂度和调试难度
• JDK 15起默认关闭，启用会触发deprecation警告；JDK 17+彻底移除相关代码路径