JMM通过happens-before规则保障可见性、原子性和有序性，volatile仅解决可见性与有序性但不保证原子性，synchronized则兼具三者且提供更强同步语义。
Java 内存模型（JMM）本身不直接“编写代码”，但它提供了一套规则，让开发者能**有依据地写出线程安全的并发代码**。其中，内存可见性是三大核心问题（可见性、原子性、有序性）中最基础也最常被忽视的一环。只要变量修改对其他线程“及时可见”，很多死循环、状态失效、读到陈旧值的问题就能避免。
用 volatile 保证关键状态的即时可见
当一个布尔标志、开关信号或就绪状态需要被多个线程读写时，必须声明为 volatile。它强制每次读取都从主内存加载最新值，每次写入都立即刷新到主内存，并插入内存屏障防止重排序。
- 比如停止线程的 flag：
private volatile boolean running = true;—— 否则子线程可能永远卡在while(running)中 - 再如初始化完成标志：
private volatile boolean initialized = false;，配合普通变量赋值，可安全实现双重检查锁之外的轻量初始化 - 注意：volatile 不能替代 synchronized 来保护复合操作（如
i++），它只保单次读/写操作的可见性与禁止重排
借助同步块（synchronized）天然获得可见性保障
进入 synchronized 块前，线程会清空工作内存中该锁保护的所有共享变量副本；退出时，会把修改强制刷回主内存。这意味着：所有被同一把锁保护的变量，在锁释放后对下一个获取该锁的线程必然可见。
- 适用于需要原子性 + 可见性组合的场景，例如计数器更新、对象状态切换
- 即使锁内只读不写，也能确保看到之前持有该锁线程写入的最新值（基于监视器锁规则）
- 比 volatile 更重，但语义更强、适用范围更广
利用 happens-before 规则主动建立可见性链
JMM 不靠“实时同步”，而是靠操作间的偏序关系来保证结果可见。只要 A happens-before B，那么 A 的写就对 B 的读可见。常见可靠链路包括：
立即学习“Java免费学习笔记（深入）”；
- volatile 写 → 后续任意线程对该 volatile 变量的读
- 解锁（synchronized 退出）→ 后续同锁的加锁（进入）
- Thread.start() → 新线程中所有操作
- Thread.join() → 主线程中 join 调用之后的操作
- 这些规则可传递组合：A HB B，B HB C ⇒ A HB C，可用于构建跨多线程的数据发布逻辑
避免依赖未同步的普通变量读写
普通字段（非 volatile、未受锁保护）的读写之间没有 happens-before 关系。编译器和 CPU 可能重排、缓存、延迟写入——导致另一线程看到部分更新、乱序结果甚至永远看不到更新。
- 典型陷阱：
int x = 0; boolean ready = false;先设 x=42 再设 ready=true，但无同步时，其他线程可能看到 ready==true 却 x==0 - 修复方式：将 ready 声明为 volatile，即可借助 volatile 规则让 x=42 对后续读 ready 的线程可见（因程序顺序 + volatile 规则共同作用）
- 不要试图靠 sleep、yield 或复杂逻辑“等一等”来解决可见性——这是不可靠且反模式的做法
