jmm通过主内存与工作内存的抽象模型解释可见性与重排问题：线程操作变量需经load-use-store-write流程，天然延迟导致“改了看不到”；volatile强制读写主内存并禁止重排，但不保证原子性；happens-before规则（如程序顺序、锁、volatile）确立操作可见性与顺序约束。
要解析多线程中的可见性与指令重排问题，关键不是背概念，而是理解JMM如何规定线程与内存的交互方式，并据此判断代码在真实执行中可能偏离预期的原因。
主内存与工作内存是可见性问题的根源
JMM把内存抽象成两层：所有共享变量（如静态变量、实例字段）都存在主内存；每个线程有自己的工作内存，它保存变量的副本。线程不能直接读写主内存，必须先 load（从主内存读取）、再 use（在工作内存操作）、最后 write + store（刷新回主内存）。这个过程天然存在延迟——比如线程A改了变量，还没 store 到主内存，线程B就 load 了旧值；或者线程B已 load 过一次，之后一直用缓存副本，不再重新读主内存。
常见表现就是“改了但对方看不到”，例如一个 boolean 控制标志位被设为 false 后，另一个线程仍在 while(true) 中循环。这不是代码写错了，而是 JMM 下的默认行为。
volatile 是最轻量级的可见性保障手段
给变量加上 volatile 修饰后，JMM 强制要求：
- 每次读该变量，必须从主内存 reload，不许用工作内存缓存值
- 每次写该变量，必须立即 write 到主内存，不许滞留在工作内存
- 编译器和 CPU 不得对该变量的读写做重排序（即插入内存屏障）
它不加锁、无阻塞，适合状态标志、单次写入多次读取等场景。但注意：volatile 不能保证复合操作的原子性，比如 i++ 仍需 synchronized 或 AtomicInteger。
指令重排需结合 happens-before 规则判断
重排不是 bug，而是 CPU 和编译器为提升性能做的合法优化。JMM 允许重排的前提是：**不改变单线程语义**。问题出在多线程下，两个线程看到的操作顺序可能不一致。
真正决定执行顺序的是 happens-before 规则，它是 JMM 定义的“先行发生”关系，包括：
- 程序次序规则：同一线程内，按代码顺序，前面的操作 happens-before 后面的
- 监视器锁规则：unlock 操作 happens-before 后续对同一锁的 lock 操作
- volatile 变量规则：对 volatile 写 happens-before 后续对它的读
- 线程启动/终止规则、中断规则、final 字段规则等
只要两个操作之间存在 happens-before 关系，JVM 就保证前者的执行结果对后者可见，且不会重排它们的顺序。
synchronized 和 final 也能提供可见性保证
synchronized 不仅解决互斥，还自带内存语义：
- 进入同步块前，线程会 flush 工作内存中所有变量（相当于强制 reload 主内存最新值）
- 退出同步块时，会将修改过的共享变量全部 write 回主内存
final 字段在构造器中一旦初始化完成，其他线程看到该对象时，就能看到正确的 final 值——这是 JSR-133 修复后的重要语义，避免了对象“半初始化”状态被其他线程观测到。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
