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 强制每次读都从主内存加载，每次写都立即刷回主内存，并插入内存屏障禁止相关重排序——但它只保单次读/写操作的可见性与有序性，不保复合操作原子性。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 适合场景：
boolean running状态开关、轻量级通知标志、一写多读的简单变量 - 不适合：
count++（读-改-写三步，非原子）、依赖上下文的判断（如if (flag) doSomething();中的doSomething()不受保护） - 不能和
final同时修饰一个字段：前者允许运行时修改并保证可见，后者禁止修改，语义冲突
比 volatile 更强的方案：锁与原子类
当需要同时保障可见性 + 原子性（比如计数、状态切换+副作用执行），就得上更重的同步机制。
立即学习“Java免费学习笔记（深入）”；
-
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 却忘了重排序风险，或以为加了锁就万事大吉却漏掉复合操作的临界区覆盖，都会让程序在高并发下偶然失效，极难复现和调试。
