jmm不主动保证可见性与有序性，而是通过主内存/工作内存抽象、内存屏障、volatile/synchronized/final语义及happens-before规则，协同jvm、编译器和cpu共同保障：volatile强制读写主内存并插入屏障，synchronized进出临界区同步变量，final确保构造完成可见；happens-before定义操作顺序依赖，由内存屏障落地，防止重排序与缓存不一致导致的并发错误。
JMM 本身不“主动保证”可见性与有序性，而是通过一套明确的规则和约束机制，让开发者能写出可预期的并发代码。它靠抽象模型 + 内存屏障 + 关键字语义，协同 JVM、编译器和 CPU 共同落实保障。
可见性：主内存与工作内存的同步约定
JMM 把内存逻辑划分为“主内存”（所有线程共享）和“每个线程的工作内存”（私有副本）。可见性问题的本质是：线程 A 修改了变量，线程 B 却一直读到旧值——因为 B 还在用自己的缓存副本，没去主内存刷新。
- volatile：每次读都强制从主内存加载，每次写都立即刷回主内存；同时插入内存屏障，使其他线程对应缓存失效。
- synchronized：进入临界区前清空工作内存中相关变量副本，强制重读主内存；退出时将所有修改强制写回主内存。
- final 字段：构造器完成时的隐式屏障，确保对象发布后，其他线程看到的是完全初始化的状态。
有序性：happens-before 规则 + 内存屏障
有序性不是禁止一切重排序，而是在关键位置建立执行先后的逻辑依赖。JMM 用 happens-before 定义哪些操作必须被“看见”且“按序发生”。
- 程序顺序规则：单线程内，按代码顺序，前面的操作 happens-before 后面的。
- 监视器锁规则：unlock 操作 happens-before 后续对同一把锁的 lock 操作。
- volatile 规则：对 volatile 变量的写 happens-before 后续对该变量的读。
- 传递性：如果 A happens-before B，B happens-before C，则 A happens-before C。
这些规则背后由 JVM 在字节码层面插入内存屏障（如 LoadLoad、StoreStore）来落地，防止指令重排序跨越关键边界。
为什么不能只靠编译器或 CPU 自己处理？
现代硬件有多级缓存，不同核心可能各自缓存同一变量；JIT 编译器会做激进优化（比如把循环内变量提到寄存器、调整赋值顺序）。这些在单线程下完全正确，但多线程下就会导致：
- 一个线程改了 flag = true，另一个线程永远读不到（可见性破缺）；
- instance = new Singleton() 被重排为“分配内存→赋值引用→调用构造器”，造成未初始化对象逸出（有序性破缺）。
JMM 正是为统一规范这些底层行为而存在，让 Java 程序在 x86、ARM 等不同平台上表现出一致的并发语义。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
