Java内存可见性问题指一个线程修改共享变量后另一线程无法看到最新值，源于JVM和CPU缓存机制；volatile通过强制主内存读写和内存屏障解决，但不保证原子性。
Java里内存可见性问题，就是“一个线程改了共享变量，另一个线程却看不到最新值”——不是代码写错了，而是JVM和CPU的缓存机制在背后悄悄搞鬼。
为什么while(true)死循环里改flag没用？
这是最典型的可见性失效现场。比如下面这段代码：
public class VisibilityIssue {
private static boolean flag = true;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (flag) { } // 空循环
System.out.println("Thread stopped");
}).start();
Thread.sleep(1000);
flag = false; // 主线程改了，但子线程可能永远卡住
System.out.println("Main thread updated flag");
}
}
现象：输入 false 后，子线程不退出；原因不是逻辑卡死，而是JVM把 flag 的读取优化成了“从寄存器/本地缓存反复读”，压根没再去主内存检查更新。
- 编译器或JIT认为
flag不会被其他线程修改，就做了“读提升”（hoisting）优化 - 线程的工作内存没同步，主内存的修改对它不可见
- 这不是bug，是JMM默认行为——除非你明确告诉JVM“这个变量要随时看新的”
volatile 是怎么破局的？
volatile 不是锁，也不是万能药，它只做两件事：强制读写主内存 + 插入内存屏障。
立即学习“Java免费学习笔记（深入）”；
- 写
volatile变量时，立即将值刷到主内存，且禁止该写操作与前面的指令重排序 - 读
volatile变量时，强制从主内存加载，不走工作内存缓存 - 它不保证原子性（
count++还是不行），只保可见性和有序性
修复上面的代码，只需加一个关键字：
private static volatile boolean flag = true;
注意：volatile 不能修饰局部变量，只能用于实例字段或静态字段；也不能用于 long/double 的非原子写（虽然JVM 5+已基本解决，但语义上仍建议避免）。
synchronized 也能解决可见性？怎么选？
能。进入 synchronized 块前，线程会清空工作内存、重新从主内存读所有共享变量；退出时，把修改全部刷回主内存。所以它天然带可见性保障。
- 适用场景：需要同时保证原子性 + 可见性，比如计数器、状态机切换
- 代价更高：有锁开销、可能阻塞，而
volatile是无锁的轻量方案 - 别混用：一个用
volatile写，另一个用synchronized读，依然可见——因为synchronized退出时的刷新动作满足 happens-before 规则
还有哪些坑容易被忽略？
可见性不是孤立问题，它常和重排序、指令优化耦合出现：
-
volatile不能防止“复合操作”的中间态暴露，比如if (flag && data != null)中，data仍可能为 null —— 因为data本身没加volatile - 对象引用设为
volatile，只保证引用本身可见，不保证其指向对象内部字段的可见性 - 用
Thread.sleep(1)强行打断循环，确实能“绕过”优化，但这是权宜之计：延迟不可控、浪费CPU、掩盖本质问题 - final 字段在构造完成时对其他线程可见，但仅限于“安全发布”场景（如构造器内赋值后不再修改），不是通用可见性方案
真正要稳，得理解 JMM 的 happens-before 链：只要两个操作之间存在这条链，前者的结果就对后者可见。而 volatile 写 → volatile 读、synchronized 解锁 → synchronized 加锁，都是标准链路。
