synchronized 的锁优化是贯穿 jdk 多个版本的系统性演进：早期依赖 os 互斥锁、开销大；jdk 1.6–14 引入偏向锁、轻量级锁、重量级锁及配套优化；jdk 15–17 逐步移除偏向锁；jdk 24+ 适配虚拟线程，重构 monitor 实现。
synchronized 的锁优化不是一次性的补丁，而是贯穿 JDK 多个大版本的系统性演进，核心目标始终是降低同步开销、适配真实并发场景。它从“能用”走向“高效”，再走向“简洁可靠”，每一步都回应了当时主流应用的瓶颈。
早期：依赖操作系统，性能沉重（JDK 1.0–1.5）
此时 synchronized 完全绑定操作系统的互斥锁（mutex）。线程争抢失败时，必须从用户态陷入内核态排队等待，一次加锁/解锁就伴随昂贵的上下文切换。这导致它在高并发下吞吐极低，开发者普遍回避使用。
黄金优化期：锁升级机制落地（JDK 1.6–14）
JVM 开始在用户态做文章，引入一套动态适应竞争强度的锁状态体系：
- 偏向锁：默认启用，对象首次被某线程锁定时，仅在对象头 Mark Word 中记录线程 ID；后续同一线程重入无需任何同步操作，近乎零成本。
- 轻量级锁：发生轻微竞争时启用，线程在栈中创建 Lock Record，通过 CAS 自旋尝试获取锁，避免立即挂起。
- 重量级锁：自旋失败或竞争加剧后，才真正膨胀为依赖 OS mutex 的阻塞锁。
- 配套优化：自适应自旋（根据历史成功率调整次数）、锁消除（逃逸分析判定无竞争则删掉锁）、锁粗化（合并相邻同步块）同步上线。
去冗余阶段：偏向锁逐步退出（JDK 15–17 LTS）
随着现代应用广泛采用无锁数据结构（如 ConcurrentHashMap），以及虚拟线程等新模型兴起，偏向锁的维护成本（撤销需全局 safepoint）反而成了负担：
- JDK 15 默认禁用偏向锁（-XX:+UseBiasedLocking 才能开启）；
- JDK 17（LTS）彻底移除偏向锁逻辑，相关 JVM 参数失效；
- 轻量级锁与重量级锁仍是主力，但实现更精简、路径更清晰。
面向未来：与虚拟线程深度协同（JDK 24+）
为支撑百万级虚拟线程调度，synchronized 底层正在重构。Monitor 不再强耦合 OS 线程，而是适配虚拟线程生命周期管理，减少阻塞感知开销。这不是简单提速，而是让同步原语能自然融入轻量级并发范式。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
