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

锁升级路径直接影响系统吞吐量，核心在于不同锁状态带来的开销差异逐级放大。不是锁“本身慢”，而是竞争加剧后状态跃迁触发更重的执行代价。

偏向锁：单线程场景下的零成本入口

对象刚被一个线程首次加锁时，JVM在Mark Word中记录该线程ID，后续同一线程重复进入无需CAS或系统调用。此时同步块几乎无额外开销，适合缓存读取、配置加载等单线程高频访问场景。一旦其他线程尝试获取同一把锁，偏向锁立即撤销并升级——这个过程本身不阻塞，但会引发一次全局安全点暂停（safepoint），在超高频调用下也可能成为隐性瓶颈。

轻量级锁：短竞争下的自旋博弈

当第二个线程到来，JVM将锁升级为轻量级锁，通过CAS把当前线程栈帧中的锁记录地址写入对象头。若失败则自旋重试，默认最多10次（可通过-XX:PreBlockSpin调整）。这阶段仍停留在用户态，避免内核切换，但自旋本身消耗CPU。若多个线程反复争抢且临界区稍长（比如含毫秒级IO或计算），自旋失败率升高，就会快速触发下一步升级。

重量级锁：吞吐量断崖的起点

一旦自旋失败达到阈值，JVM将锁膨胀为重量级锁，对象头指向操作系统Mutex。此时：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 未抢到锁的线程立刻被挂起，进入BLOCKED状态，放弃CPU时间片
• 每次加锁/解锁都引发用户态→内核态切换，实测耗时从纳秒级跳至5–30微秒
• 线程唤醒需等待调度器重新分配时间片，引入不可控延迟
• 所有对该对象的同步操作彻底串行化，哪怕只改一个字段，其他线程也无法并发执行任何同步块

锁升级如何拖垮整体吞吐

高并发写操作天然加速锁升级进程。例如电商库存扣减接口，每秒万级请求打在同一Inventory实例上：

• 前几毫秒可能还处于偏向锁，响应极快
• 几十毫秒内迅速升级到轻量级锁，CPU自旋开始明显升温
• 不到一秒就全面进入重量级锁，线程大量阻塞，QPS骤降、平均延迟飙升
• 线程上下文切换频次激增，CPU spend在调度而非业务上，形成恶性循环

这不是个别方法的问题，而是热点对象让整个同步路径变成单点瓶颈，进而拉低整个服务的处理能力。