Java多线程同步需系统设计，核心是保障共享资源访问的可预期性；重点保护三类场景：多线程读写的状态变量、对象引用变更的集合、业务原子操作组合；synchronized需明确锁对象与范围；ReentrantLock适用于尝试加锁、响应中断及多条件等待；volatile仅保证可见性与有序性，不保证原子性。
Java 多线程编程中，同步与并发安全控制不是“加个 synchronized 就完事”，而是围绕共享资源的访问逻辑、锁的粒度、可见性保障和协作机制做系统性设计。核心目标只有一个：让多个线程操作同一份数据时，结果可预期、不丢失、不混乱。
明确哪些变量或操作需要同步
不是所有字段都需要加锁。重点盯住三类场景：
- 被多个线程读写的状态变量：比如计数器、余额、缓存开关标志等。单次读写看似原子（如 int 赋值），但 ++、--、+= 等复合操作实际包含“读-改-写”三步，必然引发竞态条件。
- 对象引用状态发生变更的集合或容器：例如 ArrayList 在多线程 add 时可能扩容失败、数据错乱；HashMap 在并发 put 时可能触发死循环（JDK 7）或数据覆盖（JDK 8+）。不能只靠 volatile 修饰引用本身，而要保护其内部结构变化。
- 业务上具有原子语义的操作组合：比如“查余额 → 判断是否足够 → 扣款”，这三步必须整体串行化，否则会出现超扣或重复扣款。
synchronized 的正确用法与常见误区
synchronized 是最常用也最容易误用的同步工具。关键在“锁谁”和“锁多大范围”：
- 实例方法加 synchronized：锁的是当前 this 对象，适用于保护该对象的成员变量。不同实例之间互不影响。
- 静态方法加 synchronized：锁的是当前 Class 对象（如 MyService.class），对所有该类实例全局生效，适合保护静态资源。
- 同步代码块指定锁对象：推荐方式。避免直接锁 this 或 getClass()，而应使用私有 final Object lock = new Object(); 这样能精准控制锁范围，防止外部干扰或意外锁升级。
- 不要在同步块里调用外部方法：尤其是可能阻塞或回调的方法（如 I/O、远程调用、监听器通知），容易导致锁持有时间过长，甚至引发死锁。
ReentrantLock 提供更精细的控制能力
当 synchronized 不够用时，ReentrantLock 是更灵活的选择，尤其适合以下情况：
立即学习“Java免费学习笔记（深入）”；
- 需要尝试获取锁而不阻塞：用 lock.tryLock()，可设定超时时间，避免线程无限等待。
- 需要响应中断：lock.lockInterruptibly() 允许在等待锁过程中被 Thread.interrupt() 中断，提升程序可控性。
- 需要多个条件变量配合：通过 newCondition() 创建多个 Condition 实例，实现类似“生产者等待队列满、消费者等待队列空”的差异化唤醒。
- 务必在 finally 块中 unlock()：这是硬性要求。漏掉会导致锁永远无法释放，后续线程全部卡死。
volatile 不是万能的，但它解决特定问题很高效
volatile 主要保证两点：变量修改对其他线程立即可见、禁止指令重排序。但它不保证原子性：
- 适合场景：状态标志位（如 running = false）、单次写入后只读的配置项、双重检查锁中的单例引用（配合 synchronized 使用）。
- 不适合场景：count++、map.put(key, value) 这类非原子操作。即使变量声明为 volatile，++ 操作仍会出错。
- 注意内存屏障语义：volatile 写操作前的所有普通读写，不能被重排到写之后；volatile 读操作后的所有普通读写，不能被重排到读之前——这是它实现可见性的底层机制。
