堆内存过大导致full gc停顿显著拉长，需通过jstat和gc日志确认老年代使用率＞75%、full gc耗时＞500ms或占比超20%；应设-xms与-xmx相等，建议为物理内存1/4～1/3，并调大年轻代占比、优化survivorratio、避免大对象直入老年代；大堆（6gb+）推荐g1回收器。
堆内存设得过大，最直接的后果就是 Full GC 停顿时间显著拉长——一次停顿可能持续数秒甚至十几秒，对在线服务来说非常危险。这不是“内存多就稳”，而是“大而不当”引发的 STW（Stop-The-World）放大效应。
看数据，别猜内存是否过大
先确认问题是否存在，而不是凭经验拍板：
- 用 jstat -gcutil
1000 5 观察老年代使用率（O列）是否长期高于75%，且伴随 Full GC 频繁发生 - 开启 GC 日志：-Xloggc:/path/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，检查日志中 Full GC 的平均耗时是否超过 500ms
- 对比 Young GC 和 Full GC 的停顿比例：若 Full GC 耗时占总 GC 时间 20% 以上，说明老年代压力已失衡
调小堆内存，但要留出合理缓冲
目标不是一味压低，而是让堆大小匹配真实负载：
- 将 -Xms 和 -Xmx 设为相同值（如 -Xms2g -Xmx2g），避免运行时扩容抖动
- 初始建议设为物理内存的 1/4 到 1/3（例如 16GB 物理内存 → 堆设 4GB～5GB）
- 如果应用峰值堆使用长期稳定在 1.8GB 左右，可尝试设为 -Xms2g -Xmx2g，而非盲目设成 8g
同步优化分代比例，减少晋升压力
光缩堆不够，还要防止对象过早进入老年代：
- 调大年轻代占比，比如用 -XX:NewRatio=1（即新生代:老年代 = 1:1），或直接设 -Xmn1g（在 2g 堆中分配 1g 给年轻代）
- 确保 -XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1），给对象多几次 Minor GC 存活机会
- 避免大对象直入老年代：检查是否误配了 -XX:PretenureSizeThreshold，没特殊需求建议不设或设高些（如 4m）
换更适应大堆的回收器
如果业务确实需要较大堆（比如 6GB+），默认 Parallel GC 不再合适：
- JDK 8u2xx+ 或 JDK 11+ 推荐启用 G1：-XX:+UseG1GC -XX:MaxGCPauseMillis=200
- 若延迟要求极高（ZGC：-XX:+UseZGC
- 禁用 System.gc()：加 -XX:+DisableExplicitGC，防止代码误触发 Full GC
