Java 中 synchronized 锁优化的最新进展与技术趋势

Java 中 synchronized 的锁优化已经走过了那个“是否需要优化”的争论阶段，现在的问题是：怎么让锁精准适配具体场景。从 JDK 16 开始，官方默认把偏向锁关掉了，到了 JDK 17 及以上版本，偏向锁的代码被彻底删除。接替它的是轻量级锁和自适应自旋——这俩成了主力。再加上虚拟线程（Project Loom）正式落地，整个锁竞争模型都变了：高并发不再等于高线程数，而是更强调协作式调度下的锁粒度控制。

偏向锁的正式退出与原因

偏向锁从 JDK 15 开始实验性弃用，JDK 16 默认关闭（通过 -XX:-UseBiasedLocking），到了 JDK 17 及以后，代码直接没了。根本原因不是性能差，而是维护成本太高。在多核、多线程交替访问的场景下，频繁的锁撤销（revoke）反而引入了额外开销。再加上现在的主流应用普遍使用池化线程（比如 ForkJoinPool、Netty EventLoop）或者虚拟线程，那种单线程长期持有锁的典型场景已经很少见了。所以，偏向锁的退出其实是合理的技术取舍。

轻量级锁与自适应自旋的持续强化

当前 HotSpot JVM（JDK 17–21）对轻量级锁的优化重点放在两个方向：

• 更智能的自旋策略：自旋次数不再固定，而是基于这把锁的历史获取成功率、持有时间、当前 CPU 负载动态调整。如果检测到锁持有者正在执行 I/O 或 GC，会提前放弃自旋，避免空转浪费。
• 栈上替换（Stack Locking）增强：JIT 编译器在逃逸分析确认对象未逃逸时，可以把锁记录直接分配在栈帧内，跳过对象头 Mark Word 的修改，进一步降低原子操作的开销。

锁消除与锁粗化的编译期深度协同

现代 JIT（特别是 GraalVM 和 HotSpot 的 C2 编译器）把锁优化前移到了方法内联与控制流分析阶段：

• 锁消除不再局限于局部变量同步（比如 new StringBuilder().append(...)），还能识别链式调用中那些无共享状态的中间对象，整段同步块被整体剔除。
• 锁粗化支持跨字节码边界合并。举个例子，连续调用多个 synchronized 方法且锁对象相同时，JIT 可以把它们合并成一个外围同步区域，减少 monitor 进入/退出的次数。

与虚拟线程（Virtual Threads）的协同演进

Project Loom（JDK 21 正式 GA）彻底改变了锁的设计范式：

• 传统的“一个线程一个锁”模型被弱化。大量虚拟线程可能共享少量平台线程，锁竞争更多体现为调度时序，而不是 CPU 核心争抢。
• synchronized 在虚拟线程环境下依然保持语义正确性，但推荐配合 StructuredTaskScope 使用，避免长临界区阻塞整个 carrier 线程。
• JVM 层面对 monitor 的等待队列做了轻量化重构，支持百万级虚拟线程挂起，而不会显著增加内存占用。

其实有个点不复杂但容易被忽略：synchronized 现在的性能优势主要来自 JIT 的上下文感知优化，开发者手动调优反而意义不大。与其纠结该用哪种锁，不如把注意力放在更根本的问题上——临界区是否真的必要？数据能不能局部化？能不能用不可变对象或并发容器来替代同步？这些才是决定性能的关键。