锁升级路径为偏向锁→轻量级锁→重量级锁,直接影响系统吞吐量:偏向锁在单线程场景下近乎零开销;轻量级锁通过cas自旋避免内核切换但消耗cpu;重量级锁触发线程阻塞与内核态切换,导致吞吐量断崖式下降。

锁升级路径直接影响系统吞吐量,核心在于不同锁状态带来的开销差异逐级放大。不是锁“本身慢”,而是竞争加剧后状态跃迁触发更重的执行代价。
偏向锁:单线程场景下的零成本入口
对象刚被一个线程首次加锁时,JVM在Mark Word中记录该线程ID,后续同一线程重复进入无需CAS或系统调用。此时同步块几乎无额外开销,适合缓存读取、配置加载等单线程高频访问场景。一旦其他线程尝试获取同一把锁,偏向锁立即撤销并升级——这个过程本身不阻塞,但会引发一次全局安全点暂停(safepoint),在超高频调用下也可能成为隐性瓶颈。
轻量级锁:短竞争下的自旋博弈
当第二个线程到来,JVM将锁升级为轻量级锁,通过CAS把当前线程栈帧中的锁记录地址写入对象头。若失败则自旋重试,默认最多10次(可通过-XX:PreBlockSpin调整)。这阶段仍停留在用户态,避免内核切换,但自旋本身消耗CPU。若多个线程反复争抢且临界区稍长(比如含毫秒级IO或计算),自旋失败率升高,就会快速触发下一步升级。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
重量级锁:吞吐量断崖的起点
一旦自旋失败达到阈值,JVM将锁膨胀为重量级锁,对象头指向操作系统Mutex。此时:
- 未抢到锁的线程立刻被挂起,进入BLOCKED状态,放弃CPU时间片
- 每次加锁/解锁都引发用户态→内核态切换,实测耗时从纳秒级跳至5–30微秒
- 线程唤醒需等待调度器重新分配时间片,引入不可控延迟
- 所有对该对象的同步操作彻底串行化,哪怕只改一个字段,其他线程也无法并发执行任何同步块
锁升级如何拖垮整体吞吐
高并发写操作天然加速锁升级进程。例如电商库存扣减接口,每秒万级请求打在同一Inventory实例上:
- 前几毫秒可能还处于偏向锁,响应极快
- 几十毫秒内迅速升级到轻量级锁,CPU自旋开始明显升温
- 不到一秒就全面进入重量级锁,线程大量阻塞,QPS骤降、平均延迟飙升
- 线程上下文切换频次激增,CPU spend在调度而非业务上,形成恶性循环
这不是个别方法的问题,而是热点对象让整个同步路径变成单点瓶颈,进而拉低整个服务的处理能力。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










