Java内存模型（JMM）是一套抽象规范，定义主内存与工作内存间变量读写、同步及可见性的逻辑规则：变量须先拷贝至工作内存再操作，修改后必须写回主内存，可见性需volatile/synchronized等机制保障。
Java 内存模型（JMM）不是物理内存图，而是一套关于“线程怎么看到共享变量”的行为契约。它不画堆栈结构，只规定主内存和工作内存之间变量读写、同步与可见的逻辑规则——核心就三点：变量必须先拷贝再操作、修改必须回写、可见性需靠机制保障。
主内存与工作内存到底是什么
主内存是所有线程共享的逻辑区域，存放实例字段、静态字段、数组元素等可被多线程访问的变量；工作内存是每个线程私有的逻辑空间，保存该线程用到的那些共享变量的副本（不是对象整体，只是字段值）。注意：工作内存不是 JVM 运行时数据区里的某一块真实内存，它可能落在 CPU 缓存、寄存器或栈帧里，具体由 JVM 实现决定，但行为必须符合 JMM 约束。
关键点在于：线程不能直接读写主内存中的变量，所有操作都必须经过“加载副本→本地计算→写回主存”这个链条。
变量同步的八步交互流程
JMM 定义了 8 种原子操作来规范变量在主内存与工作内存之间的流动，它们成对出现、不可拆分：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- read：从主内存读取变量值
- load：把 read 的值放入工作内存的变量副本
- use：把工作内存变量值传给执行引擎
- assign：把执行结果赋给工作内存变量
- store：把工作内存变量值传回主内存
- write：把 store 的值写入主内存对应变量
- lock：锁定主内存变量，标识为线程独占
- unlock：释放主内存变量锁
例如普通 int i++ 操作，实际触发 read→load→use→assign→store→write 六步，中间没有 lock/unlock 保护，因此不具备原子性——两个线程可能同时读到旧值，各自加 1 后写回，最终只增 1。
可见性、有序性、原子性怎么保障
这三性不是自动生效的，而是通过 JMM 提供的机制协同达成：
- 可见性：靠 volatile、synchronized、final 字段、锁释放/获取等建立 happens-before 关系，确保一个线程的写操作对另一个线程可读
- 有序性：靠 volatile 插入读/写屏障、synchronized 块隐含的指令边界、happens-before 规则约束重排序范围
- 原子性：基本类型（除 long/double）的单次读写是原子的；i++、count++ 这类复合操作需用 synchronized、Lock 或 AtomicInteger 显式保证
volatile 能让每次读都从主内存取、每次写都立即刷回，但它不阻止 count++ 中的“读-改-写”三步被其他线程穿插，所以仍可能丢失更新。
happens-before 是真正的落地规则
它不定义执行顺序，而是定义“操作 A 的结果对操作 B 可见”的前提条件。常见关系包括：
- 同一线程中，前面的语句 happens-before 后面的语句（控制流意义上的先后）
- 对同一个锁，unlock happens-before 后续对该锁的 lock
- 对 volatile 变量，写 happens-before 后续任意线程对该变量的读
- Thread.start() happens-before 子线程任何动作；子线程所有操作 happens-before Thread.join() 返回
没有 happens-before 关系的操作，JVM 和 CPU 就可能重排，也可能看不到最新值。别以为“我先写了你后读就一定看到”，没规则，就没有保障。
