JMM是Java为解决多线程可见性、有序性、原子性问题制定的内存模型规则，规定变量存于主内存，线程操作需通过工作内存读写，volatile仅保证可见性与禁止重排序，不保证原子性与互斥，happens-before是判断操作可见性的逻辑先行关系。
JMM不是物理内存结构，而是Java为解决多线程下“变量改了别人看不见、执行顺序乱了、操作一半被插队”这三类问题，定的一套规则。 它不描述堆栈在哪，只规定：变量必须存在主内存；每个线程操作前得先拷一份到自己的工作内存；改完必须写回去，读之前得重新拉最新值——否则就可能卡死、算错、永远等不到结果。
主内存 vs 工作内存：为什么 ready = true 后另一个线程还在死循环？
这是最典型的可见性失效场景。线程A把 ready 写成 true，但只更新了自己工作内存，没刷回主内存；线程B一直从自己工作内存里读 ready，始终是 false。
- 主内存是共享的，存所有实例字段、静态字段、数组元素（
volatile和final字段也在此） - 工作内存是线程私有的，不是JVM运行时数据区里的“栈”或“本地方法栈”，而是一个抽象概念，涵盖CPU缓存、寄存器、写缓冲区等硬件优化层
- 局部变量、方法参数不在JMM管理范围内——它们天生线程私有，不存在可见性问题
- 变量访问流程强制分步：
read→load→use→assign→store→write，中间任何一步缺失或延迟，都可能导致不一致
volatile 怎么破局？它管什么、不管什么？
volatile 是JMM提供的轻量级同步机制，它直接作用于这8个原子操作中的 read/load 和 assign/store/write，强制每次读都从主内存拉、每次写都立刻刷主内存。
- ✅ 保证可见性：一个线程写
volatile变量，其他线程后续读一定能见到新值（靠volatile变量规则的 happens-before 保障） - ✅ 禁止指令重排序：编译器和CPU不会把对
volatile变量的读写“挪”到临界区外（如单例双重检查锁中防止对象未构造完成就被引用） - ❌ 不保证原子性：
count++即使count是volatile，仍是“读-改-写”三步，仍可能丢更新；要用AtomicInteger或synchronized - ❌ 不提供互斥：多个线程同时进
volatile标记的临界区，不会排队，只是“大家都能看到最新状态”
happens-befor
它不是内存操作，而是一组**逻辑先行关系**，用来判断“操作A的结果是否对操作B可见”。只要满足任一 happens-before 规则，JMM就保证A对B可见且不重排序——开发者不用纠结底层怎么刷缓存，只看代码逻辑是否符合这些规则。
- 程序顺序规则：同一线程内，前面的语句
happens-before后面的语句（即使被重排序，效果也等价） - 监视器锁规则：
unlock()happens-before后续任意线程的lock() -
volatile变量规则：volatile写happens-before后续任意线程对该变量的读 - 线程启动规则：
Thread.start()happens-before新线程的任意动作 - 传递性：若 A
happens-beforeB，Bhappens-beforeC，则 Ahappens-beforeC
真正容易被忽略的是：happens-before 是**充分不必要条件**——不满足它不一定出错（比如碰巧缓存同步了），但一旦出错，几乎肯定是因为它断了。调试并发Bug时，第一反应不该是加日志，而是画出关键变量的 happens-before 链，看哪一环断了。
