怎么理解 Java 内存模型（JMM）中的主内存与工作内存的交互规范

聊到 Ja va 内存模型（JMM），很多人一上来就被“主内存”和“工作内存”这两个概念绕晕了——它俩既不是堆也不是栈，更不是物理内存的某种分区，而是一套用来描述线程间共享变量如何交互的抽象规则。想搞清楚它们之间的交互规范，其实只需要抓住三个核心问题：谁存了什么、数据怎么传、什么时候同步。

主内存与工作内存分别存什么

主内存里放的是所有线程都能读写的共享变量——包括实例字段、静态字段、数组元素。这些是真正的“源头数据”，线程之间要协作，靠的就是它们。
而工作内存呢？每个线程私有的副本空间，不存对象本身，只保存当前线程用到的那些共享变量的本地副本。至于局部变量、方法参数，它们天生就在线程栈帧里，不涉及共享，所以 JMM 压根不管它们。

8 种交互操作必须成对且有序

JMM 定义了 8 个原子操作来规范变量在主内存和工作内存之间的流动。原子操作意味着不能拆分，而且必须按规则成对出现：

• read + load：线程想读一个共享变量，得先 read 从主内存把值取出来，再 load 到自己的工作内存副本中。这两步必须连续进行，不能只执行一半。
• use + assign：执行引擎要使用变量值（use），或者把计算结果赋给变量（assign），这些操作都只发生在工作内存内部。
• store + write：线程修改完变量后，先 store 把值放到主内存的缓冲区，再 write 写回主内存的对应位置。同样不可分离。
• lock + unlock：这两个操作作用于主内存变量，用来实现排他访问——synchronized 的底层机制就依赖它们。

同步不是自动发生的，靠关键字触发屏障机制

工作内存里的副本不会“自动刷新”也不会“实时回写”。它什么时候同步、怎么同步，全看代码里用了哪些关键字：

• 对 volatile 变量读：强制丢弃工作内存中的旧值，重新从主内存执行 read/load；写：强制把本次及之前的所有写操作（包括非 volatile 变量）都刷入主内存。
• 进入 synchronized 块之前，会隐式执行 read/load，确保能看到锁释放前的最新值；退出 synchronized 时，强制 store/write 所有已修改的变量。
• final 字段在构造器结束的那一瞬间，JMM 就保证它的值对其他线程可见——这是通过禁止重排序加上写屏障来实现的，不是靠反复同步。

常见误区提醒

别把工作内存理解成“虚拟机栈”或“本地方法栈”的某种变体，它本质上更接近 CPU 寄存器加缓存的那套语义效果。
也别觉得 volatile 能直接让 counter++ 变得安全——volatile 只管单次读或写的可见性，而“读-改-写”这三步之间没有原子性保证。
更不要把 JMM 和堆内存溢出、GC 日志混为一谈，那是 JVM 内存结构层面的东西，和 JMM 压根不在同一个维度。