内存可见性问题指多线程下共享变量修改未能及时同步到主内存，导致其他线程读取过期值。Java中volatile通过强制主内存读写保证可见性和禁止指令重排序，适用于状态标志等简单场景；synchronized在加锁时清空本地内存并刷新主内存，同时保障可见性、原子性和有序性，适合复合操作。两者性能与功能不同，应根据是否需要原子性及操作复杂度选择。
在多线程编程中，内存可见性问题是一个常见且容易被忽视的陷阱。当多个线程访问共享变量时，由于CPU缓存、编译器优化等原因，一个线程对变量的修改可能不会立即被其他线程看到，从而导致程序行为异常。Java提供了多种机制来解决这个问题，其中 volatile 和 同步（synchronized） 是最常用的两种手段。
什么是内存可见性问题？
现代JVM运行时，每个线程都有自己的工作内存（本地缓存），它保存了主内存中变量的副本。当线程读写变量时，通常操作的是本地副本。如果没有适当的同步机制，一个线程对共享变量的修改可能长时间不刷新到主内存，或者其他线程没有重新从主内存加载最新值，这就造成了“看不到更新”的现象。
例如：线程A修改了一个布尔标志 running = false，但线程B仍在继续循环，因为它读取的是自己缓存中的旧值。
volatile 如何保证可见性
使用 volatile 关键字修饰变量可以确保该变量的每次读操作都从主内存中获取，每次写操作都立即刷新回主内存。同时，volatile 还禁止了指令重排序，增强了有序性。
立即学习“Java免费学习笔记（深入）”；
适用场景：
- 状态标志位（如控制线程运行的开关）
- 双检锁单例模式中的实例引用
- 不需要复合操作的简单读写
示例代码：
<font face="Courier New">
private volatile boolean running = true;
public void run() {
while (running) {
// 执行任务
}
}
</font>
此时，一旦另一个线程将 running 设为 false，所有正在循环的线程都能很快看到这个变化。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
synchronized 如何解决可见性与原子性
synchronized 不仅能保证同一时刻只有一个线程进入临界区（互斥性），还能确保线程在进入和退出同步块时自动与主内存进行数据同步。
具体来说：
- 进入 synchronized 块前，会清空本地变量副本，从主内存重新加载
- 退出 synchronized 块时，会将修改的变量刷新回主内存
- 天然支持原子操作，适合复杂逻辑（如i++）
示例：
<font face="Courier New">
private int counter = 0;
public synchronized void increment() {
counter++;
}
</font>
这里不仅解决了可见性，还防止了多个线程同时修改导致的数据竞争。
volatile 与 synchronized 的对比
两者都能解决可见性问题，但在功能和性能上有明显区别：
| 特性 | volatile | synchronized |
|---|---|---|
| 可见性 | ✔️ | ✔️ |
| 原子性 | ❌（仅限单次读/写） | ✔️（整个代码块） |
| 有序性 | ✔️（通过禁止重排序） | ✔️ |
| 性能开销 | 低 | 较高（涉及加锁） |
| 使用场景 | 简单状态标志、单例模式 | 复合操作、方法同步 |
选择建议：
- 如果只是需要保证一个变量的修改对其他线程可见，且操作是原子的（比如赋值），用 volatile 更高效
- 如果涉及多个变量协调、复合操作（如读-改-写），必须使用 synchronized 或 ReentrantLock 等锁机制
基本上就这些。理解 volatile 和 synchronized 的差异，有助于写出既正确又高效的并发程序。关键是根据实际需求选择合适工具，避免过度同步影响性能，也别因省事而忽略原子性问题。
