synchronized 解决可见性靠 JVM 锁操作的内存语义约束：加锁时清空工作内存并从主存重载变量，解锁时强制将所有修改刷回主存，依赖 happens-before 规则保障读线程看到写线程最新值，兼具原子性与有序性，不同于 volatile 的单变量轻量同步。
synchronized 解决可见性问题，靠的是 JVM 对锁操作的内存语义约束，不是靠“加锁”本身，而是加锁和解锁时强制发生的内存同步动作。
加锁时强制读取最新值
线程进入 synchronized 块前，必须先获取锁。此时 JVM 要求该线程清空自己工作内存中所有与该锁关联的共享变量副本。之后，它只能从主内存重新加载这些变量的当前值——确保看到的是其他线程此前已刷入主内存的最新结果。
- 即使变量之前被缓存在 CPU 寄存器或高速缓存里，也会被丢弃
- 这个动作不依赖变量是否被声明为 volatile
- 前提是多个线程使用同一把锁（比如同一个对象实例或同一个 Class 对象）
解锁时强制写回主内存
线程执行完同步块、准备释放锁前，JVM 规定：必须把工作内存中所有被修改过的共享变量值，全部刷新到主内存中。这样后续获得同一把锁的线程，在加锁时就能读到这些更新。
- 这个刷新是“全部变量”，不限于显式修改的那几个
- 它覆盖了编译器重排序、CPU 缓存不一致等底层干扰
- 不需要手动 flush 或 sync，由 JVM 在 unlock 时自动完成
依赖 happens-before 规则建立可见性链
synchronized 的可见性保障，本质上由 Java 内存模型中的 happens-before 关系支撑：一个线程对共享变量的写操作（在 unlock 前），happens-before 另一个线程对该变量的读操作（在 lock 后）。只要锁是同一个，这条顺序关系就成立，从而保证读线程一定能看到写线程的修改。
立即学习“Java免费学习笔记（深入）”；
- 这种关系不依赖执行时间先后，而是逻辑上的先行发生
- 它让多线程代码的行为可预测，避免“看到旧值”的诡异现象
- 与 volatile 的 happens-before（写 before 读）不同，synchronized 的规则更宽泛，覆盖整个临界区
和 volatile 的关键区别
synchronized 和 volatile 都能解决可见性，但机制和适用场景不同：
- volatile 是单变量级的轻量同步，每次读写都直通主内存，但不提供原子性（如 i++ 仍会出错）
- synchronized 是块级的重量同步，天然具备原子性+可见性+有序性，适合复合操作或需要互斥的场景
- volatile 无法替代 synchronized 的锁语义（比如等待条件、防止并发修改）
- 用 synchronized 保护的变量，即使没加 volatile，也完全满足可见性要求
