jvm内存调优需依据应用特征和目标场景科学取舍：web服务重低延迟（avg pause ≤200ms），批处理重吞吐；堆结构需匹配对象生命周期，-xms/-xmx相等，-xmn设为1/3～1/2堆大小，survivorratio=6，maxtenuringthreshold=6～8；元空间需设metaspacesize与maxmetaspacesize；g1适用于4gb～16gb堆，小堆用parallel，大堆低延迟选zgc/shenandoah；必须持续分析gc日志并优先排查代码问题。
JVM 内存调优不是参数堆砌，而是围绕应用特征做有依据的取舍。真正有效的调优，往往来自对 GC 日志的持续观察、对对象生命周期的准确判断，以及对目标场景（低延迟 or 高吞吐）的清醒认知。
明确调优目标再动参数
盲目增大堆内存或切换回收器，反而可能加剧问题。必须先确认核心诉求：
- 如果是 Web 接口类服务（如支付、下单），重点压降 Full GC 频率和单次 STW 时间，目标是 avg pause ≤ 200ms；
- 如果是后台批处理任务（如日志归档、报表生成），更关注吞吐量，可接受稍长停顿，目标是 GC 时间占比
- 所有场景都应避免元空间持续增长触发 Full GC，或老年代使用率长期 > 75%。
堆结构配置要匹配对象生命周期
新生代太小，短生命周期对象没来得及回收就被挤进老年代；太大，则 Minor GC 变慢、频率升高。关键配置需联动考虑：
- -Xms 与 -Xmx 设为相等值（如 -Xms4g -Xmx4g），防止运行中扩容引发额外开销；
- -Xmn 推荐设为堆的 1/3～1/2（如 -Xmx8g → -Xmn3g～4g），确保 Eden 区足够容纳单次请求产生的临时对象；
- -XX:SurvivorRatio=6 比默认的 8 更适合高并发 Web 应用，增大 Survivor 空间可减少对象因 S 区不足而提前晋升；
- -XX:MaxTenuringThreshold=6～8 适用于多数 HTTP 请求场景，避免对象在 Survivor 区“养老”过久，也防止过早进入老年代。
元空间不能放任自流
JDK 8+ 后元空间使用本地内存，但不设限等于埋雷。Spring Boot 类多、动态代理频繁的应用极易触发元空间耗尽型 Full GC：
- -XX:MetaspaceSize=256m 是较稳妥的初始阈值，比默认 21MB 更合理；
- -XX:MaxMetaspaceSize=512m 可作为上线基线，若应用含大量 Groovy/JSR223 脚本或热部署框架，可放宽至 1g；
- 观察 GC 日志中是否频繁出现 “Metadata GC Threshold”，出现即说明需调大 MetaspaceSize。
回收器选择要落在实处
G1 已是 JDK 9+ 默认，且对 4GB～16GB 堆表现均衡，无需强求 ZGC 或 Shenandoah：
- 堆 ≤ 4GB：Parallel GC 吞吐更高，停顿也可接受；
- 堆 4GB～16GB：G1 是首选，配合 -XX:MaxGCPauseMillis=200 可约束停顿目标；
- 堆 ≥ 16GB 且要求亚毫秒停顿：ZGC 需 JDK 11+，Shenandoah 需 JDK 12+，但要注意它们对 CPU 利用率略高；
- CMS 已废弃，新项目严禁使用。
调优不是一锤定音的事。上线后必须开启 GC 日志（-Xlog:gc*:file=gc.log:time,uptime,pid,tags,level），用工具（如 GCViewer、GCEasy）定期分析趋势，再微调。代码层泄漏、缓存滥用、日志堆积等问题，永远比 JVM 参数更值得优先排查。
