JDK 6 对 synchronized 优化后引入偏向锁，分析其在无竞争环境中的性能提升原因？

本文共计681个文字，预计阅读时间需要3分钟。

它解决的根本问题不是并发控制，而是消除无竞争时的+CAS操作。在JDK 6之前，只有1个线程反覆调用synchronized方法，每次进入都要执行一次CAS去更新对象的Mark Word——看似轻量，但原子指令仍涉及内存屏障、缓存行刷新等隐含的隐秘性。偏向锁简化为一次内存读（比较线程ID），直接进入临界区，零同步原语。

触发偏向锁的三个硬性前提缺一不可

• JVM 启动参数未禁用：默认开启（-XX:+UseBiasedLocking），但 JDK 15+ 默认关闭，需显式加该参数
• 对象未计算过 hashCode：一旦调用 Object.hashCode() 或 System.identityHashCode()，对象头必须腾出空间存哈希值，会强制撤销偏向状态
• 未过 JVM 启动延迟期：默认前 4 秒内新建对象不启用偏向（-XX:BiasedLockingStartupDelay=0 可关掉）

性能收益只在特定模式下明显，且容易被误判

典型高收益场景：synchronized 修饰的 getter/setter、递归调用的同步方法、单线程循环中频繁加锁的计数器。实测显示，在纯单线程、百万次调用下，偏向锁比轻量级锁快 10%–20%，主要省在避免了 100 万次 CAS。