使用 synchronized 实现线程同步的常见问题及解决方法

理解 synchronized 的基本原理

多线程编程里，最核心的难题之一就是怎么保证共享资源在同一时刻只被一个线程访问。Ja va 里最早给出的答案，就是 synchronized 关键字。别看它语法简单，背后是一套基于对象监视器（Monitor）的完整机制。简单说，每个 Ja va 对象都自带一把内置锁——也叫监视器锁或互斥锁。线程想进入被 synchronized 修饰的同步方法或代码块时，就得先抢这把锁。如果锁此刻没人用，线程就拿锁进去干活；要是锁已经被别人占了，那不好意思，线程只能乖乖去锁池里等着，直到锁被释放。

这套锁机制保证了临界区代码的互斥访问。synchronized 可以用在实例方法、静态方法上，也可以显式指定某个对象来修饰代码块。关键区别在于“锁对象”是谁：修饰实例方法时，锁的是当前实例（this）；修饰静态方法时，锁的是当前类的 Class 对象。很多人踩坑，根源就在没搞清这个锁到底锁了谁。认清“锁对象”，才是正确使用 synchronized 的第一步。

常见问题一：锁对象选择不当导致同步失效

一个很典型的错误是，以为加了 synchronized 就是万能的。比如 Web 开发中 Service 层的业务方法，用 synchronized 修饰了实例方法，锁的是当前 this 对象。Spring 默认单例模式下，容器里确实只有一个 Service 实例，似乎没问题。但细想一下：如果方法里操作的是多个不同的共享资源，或者锁定的对象根本不是所有线程竞争的那个共同目标，同步就名存实亡了。

更隐蔽的一种情况是：操作静态变量时，用 synchronized 修饰实例方法完全无效——因为不同实例有自己的锁，各锁各的，根本不干扰。正确的做法是改成静态方法，或者用 synchronized(ClassName.class) 显式锁住类的 Class 对象。还有一种常见场景：开发者想对一个共享集合做同步操作，结果把锁加在了集合里的某个元素或者某个无关对象上，这同样没法保证数据一致。解法很直接：先明确要保护哪些共享资源，然后确保所有访问资源的线程都去抢同一把锁。

常见问题二：死锁的产生与避免

死锁大概是同步编程里最让人头疼的问题了。场景通常是这样：线程 A 拿着锁对象 X，还想拿 Y；同时线程 B 拿着锁 Y，还想拿 X。两方互不相让，谁也不肯放手，结果双双陷入永久的等待。这个经典模型几乎在所有锁机制里都会出现。

死锁的发生需要同时满足四个条件：互斥、持有并等待、不可剥夺、循环等待。编程时只要破坏其中任意一个，就能避免死锁。一个很实用的做法是规定锁的获取顺序——比如要求所有线程都按相同的全局顺序（像根据对象哈希值大小）来申请多个锁，这样循环等待就被打破了。另一种思路是使用尝试获取锁的机制，比如 ja va.util.concurrent.locks.Lock 接口里的 tryLock() 方法，它允许线程在获取锁失败时回退或等待一段时间，而不是无限期阻塞，这有助于打破“持有并等待”条件。日常做代码审查时，嵌套的同步块是死锁的高发区，务必格外留意。

常见问题三：性能瓶颈与锁粒度优化

synchronized 虽然保证了线程安全，但用不好也会带来严重的性能损耗。本质很简单——同步就是把原本能并行做的事强行串行化。如果一个同步方法或代码块执行时间很长，或者锁的范围太大（锁粒度过粗），大量线程只能排队等待，多核 CPU 的优势被白白浪费，程序响应也会变慢。

优化锁粒度是性能调优的关键。假如一个大方法里只有几行代码涉及共享资源的修改，那就应该把 synchronized 从方法声明移到那几行代码上，并精确指定锁对象——这叫“减小同步范围”。还有一种思路是“分离锁”，把一个大对象拆成多个独立的部分，每部分用不同的锁保护。典型例子：旧的 Hashtable 所有方法同步，锁整个表；而 ConcurrentHashMap 采用分段锁，并发度大幅提升。另外一定要避免在同步块里执行耗时操作——比如 IO、网络请求或复杂计算，这类活应该挪到同步区域外面去做。

常见问题四：可见性与重排序的误解

不少开发者只知道 synchronized 能保证原子性（互斥执行），容易忽略它同时也保证了可见性和有序性。根据 Ja va 内存模型（JMM），线程进入 synchronized 块时会清空工作内存，从主内存重新读取共享变量；退出时会把自己修改过的变量值刷新回主内存。这个机制确保了一个线程中修改的结果，对之后获得锁的线程是立即可见的。

但有些代码看似正确，实则暗藏风险。比如“检查后执行”逻辑，经典案例是懒汉式单例的双重检查锁。如果缺少正确的同步，指令重排序可能导致其他线程看到一个未完全初始化的对象。旧版本 Ja va 中，需要把实例变量声明为 volatile 并结合 synchronized 才能解决。理解 synchronized 的“监视器锁规则”和 volatile 变量规则在内存模型中的交互，对写对高并发代码至关重要。对于简单的状态标志，volatile 比 synchronized 更轻量，但它不能保证复合操作的原子性。

替代方案与最佳实践

synchronized 是基础，但在更复杂的并发场景下，Ja va 的 ja va.util.concurrent 包提供了更强大、更灵活的工具。比如 ReentrantLock 有与 synchronized 相同的互斥和内存语义，但额外支持可中断锁等待、公平锁、锁绑定多个条件等高阶功能。ReadWriteLock 允许多个读线程同时访问，只在写操作时互斥，非常适合读多写少的场景。原子变量类（如 AtomicInteger）通过硬件级别的 CAS 操作实现无锁线程安全，某些场景下性能更高。

总结几条最佳实践：第一，清晰定义共享变量和不变性条件；第二，优先使用线程安全的设计，比如不可变对象、ThreadLocal 等；第三，对于简单的同步需求，synchronized 够用，但要注意锁的范围和对象；第四，遇到复杂的并发控制、性能调优或特定需求（如超时、可中断），再考虑 ja va.util.concurrent 中的高级组件。无论用哪种工具，并发代码都要保持简洁，并且经过严格的压力测试和竞态条件测试来验证正确性。