Java 中 synchronized 在开发高性能并发组件中的应用

synchronized 从来都不是什么“性能杀手”——在锁粒度合理、竞争不激烈时，它的性能可以接近无锁。语义清晰、JVM 优化成熟，它天然就是高性能并发组件中值得信赖的基础同步工具。而性能的关键，无非就是锁对象选对、锁升级用好、临界区控好，再加上与 wait/notify 的默契配合。

很多人觉得 synchronized 是上古时代的产物，能不用就不用。但实际在高性能并发组件开发中，它恰恰是最可靠、可预测、开销低的基础同步工具。它不追求极致的吞吐量，但胜在语义清晰、JVM 优化成熟、与内存模型天然契合——尤其是在锁粒度合理、竞争不激烈的情况下，性能几乎可以跟无锁媲美。

锁对象选择决定并发能力上限

高性能组件的成败，往往就卡在“锁谁”和“锁多大范围”这两个问题上。synchronized 的锁对象，必须满足唯一性，并且生命周期要跟资源匹配。具体来说：

• 实例方法锁 this：适合单例或有状态对象的局部状态保护，比如连接池里的单个连接对象，多个实例之间互不影响。
• 静态方法锁 Class 对象：仅用于全局共享状态，比如缓存统计计数器，但会成为全系统瓶颈，必须慎之又慎。
• 细粒度锁对象（如 private final Object lock = new Object()）：最常用的策略，把锁绑定到具体资源上——按 key 分段加锁、为每个 bucket 单独设锁，都能显著降低线程争抢。

避免锁膨胀，善用锁升级机制

JVM 为 synchronized 内置了三级锁优化——偏向锁、轻量级锁、重量级锁，这也是它面对高并发时依然能打的底气所在：

• 无竞争时启用偏向锁（默认开启），几乎零开销；适合长时间由单一线程访问的对象，比如线程局部缓存。
• 轻量级锁通过 CAS 操作实现，适用于短临界区、低频竞争场景，比如一次性的状态标记更新。
• 只有真实高竞争（大量线程反复阻塞/唤醒）才会升级为重量级锁（内核态线程挂起），这时应该优先考虑重构锁粒度，而不是禁用 synchronized。

同步块优于同步方法，控制临界区边界

高性能组件中，90% 的性能损耗来自于“锁得太多”，而不是“用了 synchronized”：

• 同步整个方法容易把非共享逻辑（日志、参数校验、IO 等）也拖入临界区，放大阻塞时间。
• 用 synchronized(lock) 显式包裹真正需要原子性的几行代码（如更新 volatile 字段 + 修改集合元素），让其余逻辑并行执行。
• 配合 volatile 字段做状态快照（如“是否已初始化”），可减少锁进入次数——这是双重检查锁定的经典变体。

与 wait/notify 配合实现高效协作

在组件内部需要线程协调时（如阻塞队列、资源池、信号门），synchronized 是 wait/notify 的唯一合法上下文：

• 必须在 synchronized 块内调用 wait()（释放锁并等待）、notify()/notifyAll()（唤醒等待线程）。
• 用 while 循环检测条件 防止虚假唤醒，比轮询更节能。
• 相比 Lock + Condition，synchronized + wait/notify 更轻量，无额外对象创建开销，适合高频、短时协作场景。