Java内存模型（JMM）是一套约束变量读写行为的规则集合，通过八种原子操作定义工作内存与主内存间的数据流动，并依赖happens-before关系保证可见性与有序性，需程序员显式使用synchronized、volatile等同步机制触发。
Java 内存模型（JMM）里，线程本地工作内存和主内存之间的同步协议，本质是一套**约束变量读写行为的规则集合**，不是自动运行的“同步服务”，而是由 JVM 保证执行、由程序员通过同步手段触发的协作机制。它解决的核心问题是：多个线程如何安全地共享和修改同一个变量，避免因缓存不一致、指令重排序导致的不可预期行为。
工作内存与主内存的关系不是复制粘贴，而是“副本+延迟可见”
每个线程不能直接读写主内存中的变量，必须先将变量从主内存“读取并载入”到自己的工作内存中，所有读、写、计算都在工作内存完成，最后再“存储并写入”回主内存。这个过程天然存在时间差——比如线程 A 修改了变量后还没写回主内存，线程 B 就可能仍读到旧值。
- 主内存存放的是变量的“唯一真相”，类似数据库里的源表；
- 工作内存是线程私有的“临时草稿区”，类似本地 Excel 表格；
- 两者之间没有实时双向绑定，更新需要显式触发或满足特定条件（如 volatile、synchronized）才能同步。
八种原子操作定义了同步的最小步骤
JMM 用 lock、unlock、read、load、use、assign、store、write 这八个操作，精确描述变量如何在两级内存间流动。它们必须成对、有序、原子地执行：
- 从主内存加载变量：必须按 read → load 顺序完成；
- 向主内存写回变量：必须按 store → write 顺序完成；
- 加锁（lock）和解锁（unlock）作用于主内存变量，用于排他控制；
- 单个操作本身不可分割，但 JVM 可能将多个操作合并优化——除非被同步机制禁止（如 volatile 禁止重排序）。
同步协议生效的前提是“happens-before”关系成立
单纯执行完 store/write 并不保证其他线程立即看到新值。只有当某个操作 A happens-before 操作 B 时，A 的结果才对 B 可见。常见建立该关系的方式有：
立即学习“Java免费学习笔记（深入）”；
- synchronized 块的解锁操作 happens-before 后续同锁的加锁操作；
- volatile 变量的写 happens-before 后续对该变量的读；
- 线程 start() happens-before 该线程中任意动作；
- 线程 join() happens-before 调用 join() 的线程后续动作。
没有 happens-before 关系保护的读写，就可能看到过期值、部分写入值，甚至出现“指令重排序”带来的逻辑错乱。
实际开发中要靠同步机制“激活”协议
JMM 的协议本身不自动运行。它像交通法规——规定了红灯停、绿灯行，但不会替你踩刹车。你需要主动使用语言提供的同步工具来触发正确的行为：
- 用 synchronized：确保临界区内的读写通过 lock/unlock 保证互斥，并建立 happens-before；
- 用 volatile：禁止重排序 + 强制 read/write 直接与主内存交互，适用于状态标志等简单场景；
- 用 java.util.concurrent 中的原子类（如 AtomicInteger）或显式锁（ReentrantLock），底层同样基于 JMM 规则封装了安全操作；
- 避免仅靠“变量赋值”传递状态——例如 flag = true; 不加 volatile 或同步，另一线程很可能永远看不到 true。
