synchronized 是高性能并发组件中可信赖的基础同步工具，语义清晰、JVM优化成熟，在锁粒度合理且竞争不激烈时性能接近无锁；其性能关键在于锁对象选择、锁升级机制、临界区控制及与wait/notify的协作使用。
synchronized 在高性能并发组件开发中不是“能不用就不用”的配角，而是可信赖、可预测、低开销的基础同步工具。它不追求极致吞吐，但胜在语义清晰、JVM 优化成熟、与 JVM 内存模型天然契合——尤其在锁粒度合理、竞争不激烈时，性能接近无锁。
锁对象选择决定并发能力上限
高性能组件成败常取决于“锁谁”和“锁多大范围”。synchronized 的锁对象必须具备唯一性与生命周期匹配性：
- 实例方法锁 this：适用于单例或有状态对象的局部状态保护（如连接池中的单个连接对象），多个实例间互不影响
- 静态方法锁 Class 对象：仅用于全局共享状态（如缓存统计计数器），但会成为全系统瓶颈，慎用
- 细粒度锁对象（如 private final Object lock = new Object()）：最常用策略，把锁绑定到具体资源上（例如按 key 分段加锁、为每个 bucket 单独设锁），显著降低线程争抢
避免锁膨胀，善用锁升级机制
JVM 对 synchronized 实现了三级锁优化（偏向锁 → 轻量级锁 → 重量级锁），这是它在高并发下仍具竞争力的关键：
- 无竞争时启用偏向锁（默认开启），几乎零开销；适合长时间由单一线程访问的对象（如线程局部缓存）
- 轻量级锁通过 CAS 操作实现，适用于短临界区、低频竞争场景（如一次性的状态标记更新）
- 只有真实高竞争（大量线程反复阻塞/唤醒）才会升级为重量级锁（内核态线程挂起），此时应优先考虑重构锁粒度，而非禁用 synchronized
同步块优于同步方法，控制临界区边界
高性能组件中，90% 的性能损耗来自“锁得太多”，而非“用了 synchronized”：
立即学习“Java免费学习笔记（深入）”；
- 同步整个方法容易把非共享逻辑（日志、参数校验、IO 等）也拖入临界区，放大阻塞时间
- 用 synchronized(lock) 显式包裹真正需要原子性的几行代码（如更新 volatile 字段 + 修改集合元素），让其余逻辑并行执行
- 配合 volatile 字段做状态快照（如“是否已初始化”），可减少锁进入次数（双重检查锁定的经典变体）
与 wait/notify 配合实现高效协作
在组件内部需线程协调时（如阻塞队列、资源池、信号门），synchronized 是 wait/notify 的唯一合法上下文：
- 必须在 synchronized 块内调用 wait()（释放锁并等待）、notify()/notifyAll()（唤醒等待线程）
- 用 while 循环检测条件 防止虚假唤醒，比轮询更节能
- 相比 Lock + Condition，synchronized + wait/notify 更轻量，无额外对象创建开销，适合高频、短时协作场景
