4. JVM参数调优与内存泄漏诊断

支付订单系统对响应时间与吞吐量有极高要求，JVM 参数配置不当会直接导致频繁 Full GC、CPU 飙升甚至 OOM。本章从堆内存布局、分代比例、元空间策略到内存泄漏排查工具，给出可落地的调优方案。

4.1 堆内存大小设置原则

堆内存大小直接影响 GC 频率与单次停顿时间。生产环境建议遵循以下原则：

• -Xms 与 -Xmx 相等：避免运行时动态扩容带来的性能抖动，支付服务建议初始堆与最大堆设为相同值。
• 堆大小估算：根据订单 TPS、单笔订单对象大小、峰值并发数计算。例如：单笔订单对象链约 2KB，峰值 5000 TPS，存活时间 2s，则活跃数据约 20MB，堆大小建议设为活跃数据的 3~5 倍（60~100MB），再预留 30% 缓冲。
• 避免过大堆：超过 8GB 的堆建议使用 G1GC，超过 32GB 需谨慎，因为压缩指针失效会导致内存浪费。

4.2 新生代与老年代比例调优

分代比例决定了对象晋升速率与 Full GC 频率。支付系统常见场景调优策略如下：

• 短生命周期对象多（订单请求）：增大新生代，减少对象晋升，降低 Full GC 次数。
• 长生命周期对象多（缓存、配置）：适当增大老年代，避免频繁 Full GC。
• 监控指标：通过 jstat -gcutil 观察 YGC 耗时、FGC 次数、晋升大小。若 YGC 耗时 > 50ms 或 FGC 间隔 < 1 小时，需调整比例。

4.3 元空间调优

JDK 8+ 使用元空间（Metaspace）替代永久代，存储类元数据、方法字节码等。元空间使用本地内存，默认无上限，但需防止类加载泄漏。

4.4 内存泄漏排查：MAT 与 JProfiler

内存泄漏在支付系统中表现为：堆内存持续增长、Full GC 频繁、最终 OOM。排查流程如下：

1. 获取 Heap Dump：通过 jmap -dump:live,format=b,file=heap.hprof <pid> 或 JVM 参数 -XX:+HeapDumpOnOutOfMemoryError。
2. MAT 分析：打开 dump 文件，使用 Leak Suspects Report 自动定位嫌疑对象；通过 Dominator Tree 查看大对象持有链。
3. JProfiler 分析：实时监控对象分配频率、GC 活动；使用 Heap Walker 查看对象引用路径，定位 GC Root。
4. 常见泄漏模式：ThreadLocal 未清理、静态集合持有订单对象、连接池未归还、类加载器泄漏。

4.5 实战参数模板

以下为支付订单服务经过压测验证的 JVM 参数模板（JDK 11+，G1GC）：

-Xms4g -Xmx4g
-Xmn1.5g
-XX:SurvivorRatio=8
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:InitiatingHeapOccupancyPercent=45
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/logs/heapdump.hprof
-XX:+PrintGCDetails -Xloggc:/logs/gc.log
-XX:+PrintGCDateStamps