JMM是一套定义多线程读写共享变量行为的抽象规则，规定可见性、有序性及同步机制；主内存与工作内存是逻辑概念，非物理内存；volatile保证可见性和禁止重排序，但不保证原子性。
Java内存模型（JMM）不是一段代码、一个类或JVM的物理内存布局，而是一套**定义多线程读写共享变量行为的抽象规则**——它告诉你：什么时候一个线程改了变量，另一个线程能“看见”；哪些操作不能被重排；哪些语义是“保证发生”的。没理解它，synchronized、volatile、甚至AtomicInteger都可能用错。
主内存和工作内存到底怎么交互？
别被名字骗了：主内存不是堆内存，工作内存也不是栈内存。它们是JMM为统一硬件差异虚构出来的概念：
- 所有
static、实例成员变量、数组元素都属于“主内存”（逻辑上共享） - 每个线程执行时，会把要用到的变量从主内存“拷贝一份”到自己的“工作内存”（实际是CPU缓存+寄存器等）
- 线程只能读写自己工作内存里的副本，不能直读主内存；变量同步靠8个原子动作（
read/load/use/assign/store/write等）完成
所以你写sharedVar = 1，不等于立刻刷到主内存；另一个线程读sharedVar，也不一定拿到最新值——除非有同步机制介入。
volatile为什么不能替代synchronized？
volatile只解决两个问题：可见性 + 禁止指令重排序（在读写前后插入内存屏障），但它完全不提供原子性。
立即学习“Java免费学习笔记（深入）”；
- 现象：
volatile int counter = 0;，然后100个线程各执行100次counter++，最终结果大概率 - 原因：
counter++是三步：读取→加1→写回，volatile只保证每一步的读/写可见，但三步之间不互斥，仍会交叉执行 - 正确做法：用
AtomicInteger.incrementAndGet()（CAS保障原子性），或包在synchronized块里
happens-before原则是判断可见性的唯一依据
这不是语法糖，也不是JVM优化开关，而是JMM定义的“操作先后顺序”的数学关系。只要A happens-before B，那么A的执行结果对B可见。
- 常见规则举例：
synchronized解锁 happens-before 同一锁的加锁；对volatile变量的写 happens-before 后续对该变量的读；线程start()happens-before 线程内任何操作 - 陷阱：没有happens-before关系的操作，编译器/JIT/CPU都可能重排，哪怕代码写在前面，也不代表先执行或先被看到
- 实操建议：别靠“我觉得它该按顺序执行”来推理；画出关键变量的读写路径，逐条检查是否满足某条happens-before规则
真正难的不是记住这些规则，而是在复杂对象引用链、嵌套锁、异步回调中，准确识别哪些变量需要同步、哪些操作必须建立happens-before。很多并发bug不是因为没加锁，而是加了锁却没覆盖全部共享状态——比如只锁了list，忘了list.get(0).field也是共享变量。
