Java synchronized锁升级是必要妥协，为解决JDK 1.5前重量级锁依赖OS Mutex导致的高频内核态切换与线程阻塞问题，通过无锁→偏向锁→轻量级锁→重量级锁的单向升级机制，按竞争程度动态选择最轻量同步方式，在单线程至高并发全场景实现性能收敛。

Java 中 synchronized 锁升级不是“锦上添花”，而是针对真实运行场景的必要妥协——它用少量空间与逻辑复杂度，换来了从单线程到高并发全谱系下的锁性能收敛。

为什么必须升级？直击重量级锁的硬伤

在 JDK 1.5 及之前，synchronized 一锁到底：只要加锁，就直接调用操作系统 Mutex，强制线程陷入内核态。这带来两个不可忽视的成本：

• 上下文切换开销大：一次用户态→内核态→用户态的完整切换，耗时通常在数百纳秒到数微秒级；若临界区仅执行几行赋值，锁本身开销可能远超业务逻辑
• 阻塞式等待浪费资源：线程一旦竞争失败就被挂起，CPU 资源闲置，唤醒还需再次调度——而现实中大量同步块（如 getter/setter、单例初始化）根本不存在多线程争抢

四种状态的本质：按需分配的锁资源

锁升级不是“层层加码”，而是 JVM 根据对象实际访问模式动态选择最轻量的保障方式：

Alibabacloud Sdk Client Initialization For Java

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

下载

• 无锁：对象刚创建，Mark Word 存哈希码和 GC 年龄，零成本
• 偏向锁：检测到仅线程 A 频繁进入，就把它的 ID 写进 Mark Word；后续 A 再来，只比对 ID，不 CAS、不自旋、不切内核态
• 轻量级锁：出现短暂竞争（比如两线程交替执行），改用线程栈帧里的 Displaced Mark Word + CAS 自旋；自旋成功即得锁，失败才升级
• 重量级锁：持续竞争或自旋超时后启用，此时才真正关联 Monitor 和 OS Mutex——它是兜底方案，不是默认选项

权衡的关键点：不升级的代价 vs 升级的开销

锁升级确实引入了额外逻辑（如偏向锁撤销、CAS 检查、Mark Word 状态位解析），但这些开销是可控且前置的：

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

• 偏向锁撤销有成本：当第二个线程尝试获取已偏向的锁，JVM 需暂停所有相关线程（安全点）、遍历栈帧验证锁记录、重置 Mark Word——但这只发生在“首次竞争”时刻，之后就是轻量或重量级路径
• 轻量级锁依赖自旋：自旋虽不阻塞，但会占用 CPU；JVM 默认自旋 10 次（可调），超时即升级，避免空转浪费
• 重量级锁不可逆：一旦升级为重量级，该对象后续所有同步操作都走 Monitor，即使之后再无竞争——这是设计取舍：降级逻辑过于复杂，且实际收益有限

现实中的优化效果

在典型 Web 应用中：

• Spring Bean 初始化、配置类读取等单线程场景，99% 走偏向锁路径，接近无锁性能
• 短临界区（如 ConcurrentHashMap 的 segment 锁、简单计数器），轻量级锁+自旋命中率高，避免线程挂起
• 真正长耗时同步块（如 I/O 等待、复杂计算），重量级锁虽重，但业务耗时本身已远超锁开销，此时线程挂起反而是合理选择