JMM是抽象规则而非物理内存布局，用于解决多线程共享变量的可见性、有序性、原子性问题，并屏蔽不同CPU架构差异提供统一并发语义。
JMM（Java内存模型）不是物理内存布局，而是一套抽象规则，专门用来解决多线程环境下共享变量访问的不确定性问题。它不负责分配堆或栈，而是定义线程如何读写共享变量、何时能看到彼此的修改、以及操作顺序如何被保障。
可见性：为什么改了别人看不见？
每个线程都有自己的工作内存（可理解为CPU缓存的抽象），从主内存复制变量副本后操作。线程A改了值但没及时刷回主内存，线程B还在用旧副本——这就导致“改了却看不到”。比如 flag = false 的循环可能永远不退出。
- volatile 关键字强制每次读都从主内存加载，每次写都立即刷新到主内存
- synchronized 块结束时，会把工作内存中所有共
享变量同步回主内存
- 锁的获取动作也会清空本地缓存，强制重新读取主内存最新值
有序性：代码明明这么写的，为啥执行顺序乱了？
编译器和CPU为了性能，可能调整指令顺序（如把无关的读操作提前）。单线程下没问题，但多线程中可能导致 a=1; y=b 和 b=1; x=a 这类逻辑错乱，出现 x=0, y=0 的结果。
- volatile 写操作前后插入写屏障，读操作前后插入读屏障，禁止重排序跨越屏障
- happens-before 规则提供语义保证：比如监视器锁的解锁 happens-before 后续加锁，确保解锁前的写对后续加锁线程可见
- final 字段的初始化完成 happens-before 构造方法结束，防止对象逸出时看到未初始化状态
原子性：i++ 看似简单，为何不是“一步到位”？
i++ 实际分三步：读 i、算 i+1、写回 i。两个线程同时做，可能都读到 1，都算出 2，最终只加了一次。这就是非原子操作引发的数据竞争。
- synchronized 或 ReentrantLock 可将多个操作包裹成临界区，实现整体原子性
- AtomicInteger 等原子类基于 CAS（Compare-And-Swap）指令，在硬件层面保证读-改-写不被中断
- long 和 double 的非 volatile 读写在32位JVM上甚至可能“撕裂”，即高低32位分两次写入
统一跨平台行为：x86 和 ARM 怎么做到一致？
不同CPU架构的内存一致性模型差异很大（如x86较严格，ARM/PowerPC更宽松）。JMM屏蔽底层差异，为Java程序员提供统一的并发语义——只要遵守JMM规则（如用volatile、synchronized），代码在任何平台表现一致。
- JMM通过定义8种原子内存操作（read/load/use/assign/store/write/lock/unlock）约束JVM实现
- 这些操作映射到底层时，JVM会按目标平台特性插入合适的内存屏障（如x86的mfence、ARM的dmb）
- 开发者无需关心CPU指令，只需使用Java提供的同步原语即可获得可预测行为
