Java内存模型（JMM）是一套关于共享变量读写行为的语义规范，规定线程间修改如何可见；其通过主内存与工作内存的交互流程引发可见性问题，volatile可解决可见性与有序性但不保证原子性，happens-before是判断操作顺序的唯一可靠依据。
Java内存模型（JMM）不是物理内存结构，而是一套**关于共享变量读写行为的语义规范**——它不告诉你内存长什么样，而是明确规定：当线程A改了一个变量，线程B在什么条件下、以什么方式才能看到这个改动。
为什么直接读主内存不行？工作内存是“缓存副本”不是“本地存储”
JMM把内存逻辑上分为主内存（所有线程共享，存原始变量值）和每个线程独有的工作内存（实际是CPU缓存或寄存器级别的副本）。线程不能直接读写主内存，所有操作都必须经过自己的工作内存：
-
Read：从主内存把变量值拷贝到工作内存 -
Load：把拷贝来的值加载进工作内存的变量副本 -
Use：线程执行引擎使用该副本值（比如参与计算） -
Assign：修改副本值（如i++） -
Store：把修改后的副本值传回主内存 -
Write：把值真正写入主内存
问题就出在这套流程里：如果没有同步机制，Store/Write可能迟迟不发生，或者别的线程的Read/Load永远读不到最新值——这就是可见性问题的根源。
volatile能解决什么？又为什么不能替代synchronized？
volatile关键字强制插入内存屏障（Memory Barrier），保证两点：
立即学习“Java免费学习笔记（深入）”；
- 写操作后立即
Store+Write到主内存（其他线程下次Read能拿到新值）→ 解决可见性 - 禁止对该变量的读写指令重排序（比如禁止把
flag = true重排到对象构造完成前）→ 保障有序性
但它不保证原子性。下面这段代码依然线程不安全：
public class Counter {
private volatile int count = 0;
public void increment() {
count++; // 读-改-写三步，非原子！
}
}
多个线程同时执行 count++，仍可能丢失更新。要保证原子性，得用 synchronized、ReentrantLock 或 AtomicInteger。
happens-before 是唯一可靠的顺序判断依据
别靠“代码写在前面就一定先执行”来推理多线程逻辑。JMM只认 happens-before 关系——如果操作A happens-before 操作B，那么A的结果对B可见，且A一定在B之前完成。
常见规则包括：
- 程序顺序规则：同一线程内，按代码顺序，前面的操作 happens-before 后面的
- 监视器锁规则：
unlock()happens-before 后续任意线程对该锁的lock() -
volatile变量规则：对一个volatile变量的写 happens-before 后续任意线程对该变量的读 - 线程启动规则：
Thread.start()happens-before 该线程的任何动作
这是你写并发代码时，唯一该查、该画、该验证的逻辑链。绕过它谈“应该发生什么”，十有八九会出错。
真正难的从来不是记住概念，而是意识到：JMM的每一条约束，都对应着真实硬件（CPU缓存一致性协议、编译器优化）和JVM实现的具体妥协。当你看到 volatile 不起作用、synchronized 像没加一样、甚至 final 字段被看到“未初始化”的值——那不是JVM bug，是你漏掉了某个 happens-before 链上的环节。
