JMM与GC深度耦合：JMM定义对象存活的可见性边界，GC基于JMM的可达性分析回收内存；二者协同保障多线程下对象生命周期正确性与内存可靠性。
Java 内存模型（JMM）和垃圾回收（GC）不是各自独立的机制，而是深度耦合、相互支撑的底层协同系统。JMM 为 GC 提供语义基础，GC 则在 JMM 约束下安全地释放内存——二者共同保障多线程环境下对象生命周期的正确性与内存使用的可靠性。
JMM 定义“对象是否还活着”的可见性边界
GC 判定对象是否可回收，依赖的是“可达性分析”，而可达性本身必须基于 JMM 的内存交互规则才能成立。例如：
- 一个对象被某个线程的局部变量引用，该引用存储在该线程的工作内存中；JMM 要求 assign 和 store 操作完成后，引用才对其他线程“可见”；若未同步，GC 可能误判该对象已不可达。
- volatile 字段或 synchronized 块内修改的对象引用，会触发 happens-before 关系，确保引用状态及时刷回主内存；GC Roots 扫描时依赖的就是主内存中最终一致的引用快照。
- final 字段的正确初始化也由 JMM 保证：构造器完成前的写操作对后续读线程不可见，避免 GC 在对象尚未完全构建完毕时就将其判定为“无用”。
GC 在堆内存上执行，但受 JMM 规则约束
堆是所有线程共享的主内存区域，也是 GC 的唯一作用域。然而 GC 的每次标记、清理或移动，都必须尊重 JMM 对读写顺序、可见性和原子性的要求：
- 并发收集器（如 G1、ZGC）在用户线程运行的同时进行扫描，需借助 JMM 提供的内存屏障（如 LoadLoad、StoreStore）防止重排序导致漏标或错标。
- 对象晋升到老年代、从 Survivor 区复制等操作，涉及引用字段更新；这些更新必须满足 JMM 的 write-store-use 链路，否则其他线程可能看到“半初始化”的引用状态。
- GC 后的内存重用（如 TLAB 分配、指针碰撞）也依赖 JMM 对变量初始化零值的保证，避免线程读到残留脏数据。
逃逸分析与栈上分配体现协同优化
现代 JVM（如 HotSpot）会结合 JMM 语义做运行时优化，直接影响 GC 行为：
立即学习“Java免费学习笔记（深入）”；
- 若一个对象的引用未逃逸出当前方法或线程，JVM 可依据 JMM 中局部变量的线程私有性，将其分配在栈帧中而非堆上——这样它自然不进入 GC 生命周期。
- 这种优化不是凭空发生，而是基于 JMM 对“工作内存中局部变量作用域”的明确定义；一旦逃逸分析失效（如引用被发布到静态集合），对象就必须回归堆内存，接受 GC 管理。
- 因此，JMM 不仅是安全底线，也是性能优化的语义输入源。
内存泄漏常源于 JMM 与 GC 协同断裂
很多看似“对象没被回收”的问题，实际是 JMM 层面的引用关系未按预期断开：
- 静态集合持有对象引用，但未显式清除；JMM 保证该引用持续存在于主内存，GC Roots 一直可达，对象永不回收。
- ThreadLocal 未 remove 导致本应随线程结束而消失的引用滞留；其底层依赖的是线程私有内存 + 弱引用+JMM 清理契约，任一环节失效都会引发泄漏。
- 监听器注册后未反注册，且回调中隐含强引用链；JMM 中的引用传递路径未被切断，GC 无法识别其真正不可达。
