JMM不是配置项，而是JVM规范定义的抽象内存模型与可见性规则；它依赖理解、编码约束及JVM参数协同落地，真正需配置的是堆、栈、元空间等区域的内存分配与GC策略。
Java 内存模型（JMM）不是配置项，而是 JVM 规范定义的一套抽象内存结构与可见性规则。它不靠“配”，而靠理解 + 编码约束 + JVM 参数协同来落地。真正需要配置的，是支撑 JMM 行为的底层 JVM 运行参数——尤其是堆、栈、元空间等区域的实际内存分配和 GC 策略。
下面直击重点，分四块讲清怎么“通关”：
堆内存：决定对象生命周期和 GC 压力
-
-Xms和-Xmx必须设为相同值（如-Xms12g -Xmx12g），避免运行时动态扩容带来的 STW 暂停 - 多模块/大缓存项目建议从 8G 起步，逐步调到 12–16G；但别盲目堆大，需配合 GC 日志分析实际使用率
- 新生代比例可通过
-XX:NewRatio=2（老:新 = 2:1）或-XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1）微调
虚拟机栈：防 StackOverflow 和线程OOM
- 单线程栈大小用
-Xss512k（默认通常 1M），高并发服务可适当调低（如 256k），腾出更多线程数空间 - 若日志频繁报
java.lang.StackOverflowError，优先检查递归深度或 AOP 层级过深，而非直接加-Xss - 线程总数上限受
-Xss × 最大线程数 ≤ 物理内存制约，Linux 下还受限于ulimit -u
方法区（Metaspace）：类加载不爆仓的关键
- Java 8+ 必须显式设
-XX:MaxMetaspaceSize=1024m，否则无上限，容易被动态生成类（如 Lombok、CGLIB、Spring Boot DevTools）撑爆 - 若启动时报
OutOfMemoryError: Metaspace，先jstat -gcmetacapacity <pid>查已用容量，再决定是否扩容或清理重复 Jar 包
GC 策略：让 JMM 的“ happens-before”真正低延迟生效
- JDK 17+ 推荐
-XX:+UseZGC，搭配-XX:ZCollectionInterval=10控制触发频率 - 避免混用
-XX:+UseG1GC和-XX:MaxGCPauseMillis=200这类模糊目标参数，G1 实际暂停时间波动大，ZGC 才真稳定在 1ms 内 - 启用后务必验证：
jstat -gc <pid>输出中要有ZGCT列，且ZGC字样持续出现
不复杂但容易忽略。
