JVM内存调优需围绕应用真实行为针对性配置，核心是让对象在合适的地方出生、死去，并减少GC负担；盲目增大堆内存反而可能引发更频繁的Full GC和更长停顿。
JVM 内存调优不是把 -Xmx 调大就完事，而是围绕应用真实行为做针对性配置。核心就两点：让对象在合适的地方出生、死去；让 GC 少干活、快收工。盲目堆内存，可能换来更频繁的 Full GC 和更长停顿。
明确目标再动参数
调参前先问自己：这个服务最怕什么？是接口响应慢（低延迟优先），还是批量任务跑不完（高吞吐优先）？不同目标对应不同策略：
- Web 接口类（如订单、支付）：重点压低 Minor GC 停顿和避免 Full GC，选 G1 或 CMS，-XX:MaxTenuringThreshold 设低些（6~8），防止短命对象早早进老年代
- 批处理类（如报表、ETL）：更关注吞吐量，Parallel GC 往往比 G1 更稳，-Xmn 可设为堆的 1/2，减少晋升压力
- 长期运行中间件（如 Kafka 消费者、定时任务调度器）：监控老年代增长趋势，若缓慢上升不回收，大概率是内存泄漏，调参无效，得查代码
关键堆参数怎么配
堆参数之间强关联，单改一个容易适得其反。常用组合逻辑如下：
- -Xms 和 -Xmx 必须相等：避免运行中扩容触发额外 GC，比如 -Xms4g -Xmx4g
- -Xmn 决定新生代大小：设太小（如只占堆 1/4），Eden 很快填满，Minor GC 频繁，Survivor 区装不下存活对象，大量提前晋升到老年代；设太大（超堆 2/3），老年代空间被压缩，容易触发 Full GC。推荐值为堆的 1/3～1/2
- -XX:SurvivorRatio 控制 Eden 和 Survivor 比例：默认 8 表示 Eden : S0 = 8:1。高并发短请求场景可调成 6，增大 Survivor 容量，多熬过几次 GC，减少晋升
- -XX:MaxTenuringThreshold 不必死守默认 15：对象熬不过 3 次 GC 就该进老年代？那就设成 3；如果多数对象能活 10 轮以上，设成 12 更合理
别漏掉元空间和直接内存
堆外内存出问题，一样 OOM，但错误提示不明显，容易误判。
- 元空间（Metaspace）：Spring Boot 类多、热部署频繁的应用，-XX:MetaspaceSize 至少设 256m，-XX:MaxMetaspaceSize 控制上限（512m～1g），否则动态生成类（如 CGLIB 代理）会无节制吃系统内存
- 直接内存（Direct Buffer）：Netty、NIO 文件读写常用。它不走 GC，靠 Cleaner 回收，但时机不可控。要监控 java.nio.BufferPool.direct.used 指标，必要时加 -XX:MaxDirectMemorySize 限制
- 栈内存：线程数多且递归深的服务（如复杂规则引擎），-Xss 过小会 StackOverflowError；默认 1M 通常够用，万级线程场景可降到 512k，但需同步评估单线程深度
调完必须验证效果
参数改完不验证，等于没调。用 jstat 看真实运行数据，而不是只看启动日志：
- jstat -gcutil <pid> 2000 实时观察：E（Eden 使用率）是否规律波动、O（老年代）是否缓慢爬升、FGC 是否归零
- 重点关注 YGCT（Young GC 总耗时）和 FGCT（Full GC 总耗时）占比：如果 GCT 占总运行时间 >5%，GC 已成瓶颈
- 配合 -XX:+PrintGCDetails 输出 GC 日志，分析每次 GC 回收了多少、晋升了多少、有没有内存碎片（CMS 场景尤其要看）
