线程同步的根本原因是共享变量的可见性与原子性丢失；synchronized通过互斥访问和内存屏障解决，volatile仅保证可见性不保证原子性，同步粒度不当易致性能下降或死锁。
线程同步的根本原因：共享变量的可见性与原子性丢失
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 工具类。
立即学习“Java免费学习笔记（深入）”；
容易被忽略的同步粒度与死锁风险
同步范围过大（比如整个方法体）会严重拖慢并发吞吐；过小又可能漏掉关键路径。更隐蔽的问题是嵌套锁顺序不一致引发死锁：
- 线程 A 先锁
accountA再锁accountB - 线程 B 先锁
accountB再锁accountA
这种情况下，即使每个同步块本身逻辑正确，程序也可能永久卡住。解决方案不是“少用锁”，而是统一锁顺序（比如始终按 id 升序获取锁）或改用 ReentrantLock.tryLock() 带超时机制。
