Java 中 synchronized 锁升级对代码执行效率的提升逻辑

先说一个核心判断：Java 中 synchronized 的锁升级，它的出发点并不是为了让代码跑得更快，而是通过按需匹配竞争强度，避免一上来就用高开销机制，在不同并发场景下显著减少不必要的性能损耗。背后的逻辑其实很直白：能不动操作系统，就别动；能少做一次 CAS，就少做；能不阻塞线程，就不阻塞。

锁升级的本质是“分层防御”策略

JVM 并不会预设锁的强度，而是从最轻量的状态起步，只有在检测到实际竞争时才逐步加码。这个过程就像是一套分层防御逻辑：

• 无锁 → 偏向锁：对象刚创建，或者长期被同一个线程反复调用时，JVM 会把线程 ID 直接写入对象头的 Mark Word。下一次同一个线程再进入同步块，只需要比对一下 ID，零 CAS、零内存屏障、无状态切换；
• 偏向锁 → 轻量级锁：当另一个线程试图抢锁，JVM 会撤销偏向（这步需要触发安全点），然后转为轻量级锁——每个竞争线程在自己栈帧里建一个锁记录，用 CAS 尝试把对象头指向该记录；
• 轻量级锁 → 重量级锁：如果自旋多次失败（默认是 10 次），或者参与竞争的线程变多，JVM 会放弃自旋，把锁膨胀为重量级锁，将线程挂起，交给操作系统调度。

每级升级都对应明确的开销削减目标

各级锁解决的其实是不同层面的资源浪费问题：

• 偏向锁消除“单线程反复加锁”的冗余操作：比如 Spring 单例 Bean 初始化、配置类读取这类场景，全程只有一个线程在访问。偏向锁让每次进入同步块变成一次指针比对（纳秒级），而不是传统锁的原子指令，成本几乎可以忽略；
• 轻量级锁避免“短暂竞争下的内核态切换”：假设两个线程交替执行同步块（比如一个简单的计数器更新），轻量级锁靠 CPU 自旋等待（几十到几百纳秒），远比一次用户态到内核态的切换快得多（微秒级，约 1–10 μs）；
• 重量级锁只在真正高竞争时启用：当自旋已经无法快速获得锁，说明等待时间较长，继续空转只会白白消耗 CPU。这时候阻塞线程反而是更节能的选择——把 CPU 让给其他任务，由操作系统在合适时机唤醒。

效率提升的关键不在“锁本身快”，而在“不该用重锁的地方没用”

如果没有这套机制，看看 JDK 1.5 及之前版本的 synchronized——它一上来就是重量级锁。这意味着什么？

• 哪怕只有一个线程调用 synchronized 方法，也要触发 monitor 创建、线程状态检查、甚至潜在的上下文切换准备；
• 所有同步操作都承担了应对“最坏并发”的开销，而现实中绝大多数同步场景并没有那么强的竞争；
• 低并发服务（比如内部工具类、配置加载）的吞吐量会被无形拖慢，GC 压力也可能间接上升（因为 Monitor 对象的创建和分配）。

锁升级让 JVM 实现了“按实情付费”——95% 的低竞争同步走偏向或轻量级路径，只有 5% 的高竞争场景才兜底到重量级，整体平均延迟大幅下降。

配套优化进一步放大升级收益

锁升级并不是孤立的机制，它跟 JDK 1.6+ 的其他优化是协同生效的：

• 自适应自旋：JVM 根据历史上成功自旋的次数，动态调整当前的自旋轮数。这意味着自旋不再是固定的 10 次，而是根据实际表现灵活变化，避免“该多等却没等”或者“该停却没停”；
• 锁消除：编译器如果发现锁对象不可能逃逸到当前线程之外（比如局部 StringBuilder），就会直接把 synchronized 删掉，彻底消除开销；
• 锁粗化：连续多个小同步块会被合并成一个大块，减少重复加锁和解锁的开销。

这些优化共同构成了一套“动静结合”的并发治理逻辑：锁升级管的是运行时的状态适配，编译期优化管的是静态代码结构，两者合力把同步的成本降到最低。