JMM是多线程通信的抽象规则，定义主内存与工作内存间变量可见性；JVM内存结构是运行时真实分区，包括堆、元空间、栈等，OOM和GC均发生于此。
Java内存模型（JMM）和Java内存结构是两套完全不同的概念，混淆它们是导致并发Bug和OOM排查走偏的最常见原因。前者是多线程通信的抽象规则，后者是JVM运行时真实的内存分区。下面直击实操中真正要面对的问题。
什么是JMM：它不占内存，但决定你写的并发代码是否可靠
JMM不是一块物理内存，而是一组关于“变量怎么读、怎么写、何时对其他线程可见”的协议。它的核心是主内存（Main Memory）和工作内存（Working Memory）的抽象：
- 所有
static字段、实例字段、数组元素都存于主内存（实际落在堆或方法区） - 每个线程有自己的工作内存（本质是CPU缓存+寄存器的建模），只操作变量副本
- 线程不能直接读写对方的工作内存；必须通过主内存中转——这正是可见性问题的根源
比如这段代码看似简单，却可能永远不退出：
public class VisibilityProblem {
private boolean running = true;
public void stop() { running = false; }
public void loop() {
while (running) { /* 业务逻辑 */ } // 可能无限循环！
}
}原因：线程A调用stop()后，running = false可能只写入了它自己的工作内存，未及时刷回主内存；线程B读的仍是旧副本。加volatile或synchronized才能强制同步。
立即学习“Java免费学习笔记（深入）”；
什么是JVM内存结构：它真实分配内存，OOM和GC都发生在这里
这是JVM启动后实实在在划分的几块区域，对应着OutOfMemoryError的具体类型和GC日志里的关键词：
-
java.lang.OutOfMemoryError: Java heap space→ 堆（Heap）不够，对象new太多或内存泄漏 -
java.lang.OutOfMemoryError: Metaspace→ 元空间（Metaspace）爆了，通常是动态生成类（如Spring CGLIB、Groovy脚本）过多 -
java.lang.StackOverflowError→ 虚拟机栈（Java VM Stack）溢出，常见于无限递归或过深调用 -
java.lang.OutOfMemoryError: unable to create new native thread→ 本地方法栈或线程创建失败，往往因系统级线程数超限，而非JVM参数设小
注意：String.intern()在JDK 7+后不再进方法区，而是进堆；常量池也从永久代移到堆里——这意味着-XX:PermSize在JDK 8+已失效，要用-XX:MaxMetaspaceSize。
为什么搞混JMM和内存结构会踩坑
典型误判场景：
- 看到
volatile就以为它“把变量放到了某个特殊内存区”——其实它只是插入内存屏障（LoadLoad/StoreStore等），约束读写顺序，不改变存储位置 - 调优堆大小（
-Xmx）却想解决MetaspaceOOM——方向完全反了 - 用
jstat -gc查到老年代使用率99%，第一反应是“对象没被回收”，却忽略逃逸分析可能导致的栈上分配（对象根本没进堆） - 认为“工作内存=虚拟机栈”——错。工作内存是JMM抽象，虚拟机栈是内存结构的一部分；局部变量存在栈帧里，但它们不属于JMM定义的“共享变量”，不受
volatile影响
真正关键的分水岭在于：你是在调试线程间数据不一致（选JMM），还是在定位内存耗尽/回收异常（选内存结构）。
日常开发中最该盯住的两个配置项
别被一堆参数绕晕，先守住这两条底线：
- 堆大小必须明确设：
-Xms512m -Xmx2g（避免动态扩容抖动）；新生代比例建议-XX:NewRatio=2（老年代:新生代=2:1），配合-XX:+UseG1GC应对大堆 - 元空间必须设上限：
-XX:MaxMetaspaceSize=512m（默认无上限，容易吃光系统内存）；若应用大量热部署或字节码增强，可加-XX:MetaspaceSize=256m提前触发GC
至于JMM，记住一个铁律：所有跨线程读写共享变量的场景，必须有同步手段——要么volatile（仅适用于简单状态标志），要么synchronized或java.util.concurrent工具类。靠“我觉得应该没问题”写的并发代码，99%会在高并发或不同CPU架构下暴露问题。
