synchronized性能进化是围绕“减少开销”和“适配真实并发模式”的持续重构：JDK1.5前为重量级锁；1.6–14引入锁升级与优化；15–17移除偏向锁；24+适配虚拟线程。
synchronized 在不同 JDK 版本中的性能进化，本质是一场围绕“减少开销”和“适配真实并发模式”的持续重构。它不是线性变快，而是根据主流应用场景动态调优：从早期高成本阻塞，到中期内存级优化，再到如今为虚拟线程让路的精简设计。
JDK 1.5 及以前：纯重量级锁，性能瓶颈明显
此时 synchronized 完全依赖操作系统 mutex 实现。线程获取失败即陷入内核态阻塞，每次加锁/解锁都触发用户态与内核态切换，上下文开销大。在轻度竞争下尚可，在多线程频繁争抢时，吞吐量急剧下降，常被建议用 ReentrantLock 替代。
JDK 1.6–14：锁升级机制落地，性能大幅跃升
这是 synchronized 真正“翻身”的阶段。JVM 引入多层锁状态，按竞争强度自动切换：
- 偏向锁：默认启用，首次获取锁时仅用 CAS 记录线程 ID；后续同一线程进入无需同步操作，零成本。
- 轻量级锁：出现竞争时升级，通过自旋（CAS）尝试获取，避免挂起线程，适合短临界区、低延迟场景。
- 重量级锁：自旋失败或竞争加剧后膨胀，才真正委托给操作系统，承担内核态开销。
- 配套优化还包括：锁消除（逃逸分析判定无共享，直接删锁）、锁粗化（合并相邻同步块）、自适应自旋（根据历史成功率调整自旋次数）。
这一阶段，synchronized 在多数业务场景中性能已不输甚至优于 ReentrantLock，且代码更简洁、不易漏解锁。
立即学习“Java免费学习笔记（深入）”；
JDK 15–17（LTS）：偏向锁逐步退出，逻辑回归轻量
偏向锁虽在单线程场景高效，但撤销需全局 safepoint，高并发下反而成为负担。JDK 15 开始默认禁用（-XX:+UseBiasedLocking 失效），JDK 17 彻底移除其实现。轻量级锁 + 重量级锁构成主干路径，运行时逻辑更清晰、JVM 维护成本更低，也为后续演进铺平道路。
JDK 24+：面向虚拟线程深度适配
随着 Project Loom 推出虚拟线程（Virtual Thread），传统基于平台线程的锁模型面临新挑战。synchronized 在 JDK 24 起进行底层重构，使其能与虚拟线程协同调度——例如在挂起虚拟线程时不阻塞底层平台线程，提升大规模并发下的资源利用率。这不是简单提速，而是运行模型的范式迁移。
