Java内存模型（JMM）是一套定义线程读写共享变量的抽象规则，核心解决可见性、原子性、有序性问题，通过read/load、use/assign、store/write、lock/unlock八种原子操作及其约束保障多线程安全。
Java 内存模型（JMM）不是物理内存结构，而是一套抽象规则，用来定义线程如何读写共享变量。它核心解决的是多线程环境下 可见性、原子性、有序性 三大问题。其中，read、load、use、assign、store、write、lock、unlock 这八种操作，就是 JMM 规定的、对主内存与线程工作内存之间数据传递的最小不可再分的“原子动作”。
八种操作各司其职，分工明确
它们不是独立存在的指令，而是成对或成组协作完成一次完整读/写流程：
- read + load：完成“从主内存读取变量到工作内存”。read 把值从主内存拉出来，load 把这个值真正放进工作内存的变量副本里；缺一不可，但中间可插入其他操作（比如读另一个变量）。
- use + assign：完成“使用变量并更新其值”。use 把工作内存中的值交给执行引擎（如参与计算），assign 则把引擎算出的新值写回工作内存的变量副本中。
- store + write：完成“把修改同步回主内存”。store 把工作内存的值发往主内存缓冲区，write 才真正把它写入主内存对应变量位置。
- lock + unlock：用于保证独占访问。lock 标记主内存变量为当前线程独占（同时清空该变量在其他线程工作内存中的旧值），unlock 释放锁；同一线程可重入多次 lock，但必须匹配次数的 unlock 才能真正解锁。
操作之间有强制约束，不是随意组合
JMM 不只定义动作，更规定了它们必须遵守的逻辑规则，否则就可能引发并发错误：
- read 和 load 必须成对出现——不能只 read 不 load，否则工作内存没拿到值；store 和 write 同理。
- assign 后必须同步——只要工作内存里的变量被 assign 修改过，就必须通过 store/write 回写主内存，不能丢弃变更。
- 不能无中生有——use 或 store 一个变量前，它必须已经通过 load 或 assign 初始化过；不允许直接 use 一个从未加载或赋值的变量。
- lock 操作会触发“清空”语义——一旦对某变量 lock，其他线程工作内存中该变量的副本立即失效，后续 use 前必须重新 load 或 assign。
理解这些操作的关键是区分“内存层级”和“动作目的”
主内存相当于共享数据源，工作内存相当于每个线程私有的“暂存区”。八种操作本质是在这两个层级之间搬运和加工数据：
立即学习“Java免费学习笔记（深入）”；
- read/write 面向主内存，load/store/assign/use 面向工作内存，lock/unlock 作用于主内存但影响所有工作内存。
- volatile 的可见性正是靠强化约束实现的：对 volatile 变量的 use 前必须 load（即强制从主内存读），assign 后必须立即 store/write（即强制写回主内存），从而绕过工作内存缓存，保证每次读都是最新值。
- 普通变量没有这种强制链式要求，所以可能出现线程 A 修改了变量却迟迟不写回主内存，线程 B 一直读到旧值的情况。
不必背诵字面含义，重点看它如何影响代码行为
这八种操作本身不直接出现在 Java 代码里，但每一条赋值语句、每一次变量读取，背后都隐含着它们的组合。例如：
-
int a = b + c;至少涉及：read+load b、read+load c、use b、use c、assign a（结果）； -
count++;实际包含：read+load count → use count → assign count（新值）→ store+write count；中间任何一步被其他线程打断，都可能导致丢失更新。
掌握这些操作的链条和约束，才能真正看懂 synchronized、volatile、final 等关键字为何能保障线程安全，而不是停留在“加锁就安全”的模糊认知上。
