Java线程同步必要性解析

Java线程同步的核心在于解决多线程环境下共享变量的可见性与原子性丢失问题——JVM允许线程缓存变量导致更新不可见，而复合操作（如i++）又因非原子性易被中断，从而引发不可预测的结果；synchronized通过互斥访问和内存屏障双重机制彻底保障二者，volatile则仅适用于单写多读的简单状态标志；但同步不当同样危险：粒度过大会扼杀性能，粒度不足或锁序不一致更可能触发死锁，因此必须精准设计临界区、统一锁获取顺序，并在复杂场景中善用java.util.concurrent等高级并发工具。

线程同步的根本原因：共享变量的可见性与原子性丢失

Java 中多个线程同时读写同一个 static 变量或堆上对象的字段时，不加同步会导致结果不可预测——不是因为“代码写错了”，而是 JVM 允许线程把变量缓存在自己的工作内存（CPU 寄存器或本地缓存）里，不及时刷回主内存。另一个问题是复合操作（比如 i++）在字节码层面至少拆成三步：读取、加 1、写入，中间可能被其他线程打断。

synchronized 怎么解决这两个问题

它通过“进入/退出临界区”强制实现两件事：互斥访问（同一时刻最多一个线程执行该块）+ 内存屏障（进入时清空本地缓存，退出时强制刷新所有修改到主内存）。注意：锁对象必须是同一个实例，否则无效；静态方法上的 synchronized 锁的是当前类的 Class 对象。

• 对实例方法加锁 → 锁的是 this
• 对静态方法加锁 → 锁的是 MyClass.class
• 同步代码块推荐显式指定锁对象，避免意外锁 this 引发外部干扰

为什么 volatile 不能替代 synchronized

volatile 只保证变量的可见性和禁止指令重排序，但不保证原子性。例如 volatile int counter = 0;，counter++ 依然会出错，因为读-改-写三步不是原子的。它适合用在“一个线程写、多个线程读”的简单状态标志场景，比如：

private volatile boolean isRunning = true;

// 线程中循环检查
while (isRunning) {
    doWork();
}

一旦需要读写都发生，或者涉及多个变量协同更新（如银行转账的两个账户余额），就必须用 synchronized 或 java.util.concurrent 工具类。

容易被忽略的同步粒度与死锁风险

同步范围过大（比如整个方法体）会严重拖慢并发吞吐；过小又可能漏掉关键路径。更隐蔽的问题是嵌套锁顺序不一致引发死锁：

• 线程 A 先锁 accountA 再锁 accountB
• 线程 B 先锁 accountB 再锁 accountA

这种情况下，即使每个同步块本身逻辑正确，程序也可能永久卡住。解决方案不是“少用锁”，而是统一锁顺序（比如始终按 id 升序获取锁）或改用 ReentrantLock.tryLock() 带超时机制。

本篇关于《Java线程同步必要性解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！