17370845950

volatile通过强制读写主内存和插入内存屏障解决可见性与有序性，但不保证复合操作原子性；需结合锁或原子类保障原子性。

Java里的可见性问题，就是“一个线程改了值，另一个线程死活看不见”——不是没改，是改了但没“发布”出去。

为什么 flag = true 后读线程还在死循环？

因为每个线程都有自己的工作内存（比如 CPU 缓存），flag 被修改后可能只写进了写线程的本地缓存，根本没刷到主内存；而读线程一直从自己缓存里取旧值 false，永远等不到变化。

• 线程结束、Thread.sleep()、Thread.yield() 都不构成 happens-before 关系，不能保证可见性
• JVM 和 CPU 为提速会做指令重排序：比如你写的 number = 42; ready = true;，实际可能变成 ready = true; number = 42;，导致读线程看到 ready == true 却读到 number == 0
• 编译器甚至会把 while (!flag) 优化成寄存器轮询（不重新读内存），尤其在循环体为空或只有 yield() 时

volatile 怎么解决可见性？它不是万能的

volatile 强制每次读都从主内存加载，每次写都立即刷回主内存，并插入内存屏障禁止相关重排序——但它只保单次读/写操作的可见性与有序性，不保复合操作原子性。

• 适合场景：boolean running 状态开关、轻量级通知标志、一写多读的简单变量
• 不适合：count++（读-改-写三步，非原子）、依赖上下文的判断（如 if (flag) doSomething(); 中的 doSomething() 不受保护）
• 不能和 final 同时修饰一个字段：前者允许运行时修改并保证可见，后者禁止修改，语义冲突

比 volatile 更强的方案：锁与原子类

当需要同时保障可见性 + 原子性（比如计数、状态切换+副作用执行），就得上更重的同步机制。

• synchronized 块进出时会清空/刷新工作内存中被锁保护的所有变量，天然建立 happens-before，且可嵌套、可重入
• ReentrantLock 提供相同内存语义，还支持超时、中断、公平性等控制，但必须严格配对 lock()/unlock()
• AtomicInteger 等原子类底层用 volatile + CAS，既可见又原子，适合高性能计数、状态位操作
• ConcurrentHashMap 内部已做内存屏障处理，比 Collections.synchronizedMap() 更安全高效；后者只锁方法，不保复合操作（如 if (!map.containsKey(k)) map.put(k, v); 仍可能并发出错）

public class VisibilityFix {
    private static volatile boolean flag = false; // ✅ 解决可见性
    private static AtomicInteger counter = new AtomicInteger(0); // ✅ 可见+原子

    public static void main(String[] args) throws InterruptedException {
        Thread reader = new Thread(() -> {
            while (!flag) {
                // 不再空转，volatile 保证每次读主内存
            }
            System.out.println("counter = " + counter.get()); // 一定看到最新值
        });

        Thread writer = new Thread(() -> {
            try { Thread.sleep(1000); } catch (InterruptedException ignored) {}
            flag = true;
            counter.incrementAndGet();
        });

        reader.start();
        writer.start();
        reader.join();
    }
}

最常被忽略的一点：可见性不是独立存在的——它总和有序性、原子性纠缠在一起。只加 volatile 却忘了重排序风险，或以为加了锁就万事大吉却漏掉复合操作的临界区覆盖，都会让程序在高并发下偶然失效，极难复现和调试。