减少Full GC次数的关键在于让大部分对象在年轻代内被回收，避免晋升到老年代，同时防止老年代过早或频繁填满；需结合应用特征调优堆大小、新生代比例、Survivor区配置、GC算法及对象晋升策略，并依赖GC日志持续验证优化效果。
减少 Full GC 次数的关键在于让大部分对象在年轻代（Young Gen）内被回收，避免晋升到老年代（Old Gen），同时防止老年代过早或频繁填满。JVM 参数配置需结合应用对象生命周期、内存分配模式和 GC 日志分析来调优，不是简单套用参数就能见效。
合理设置堆内存大小与比例
堆太小会导致频繁 Minor GC 和过早晋升；堆太大可能延长 GC 停顿，且若老年代过大而活跃对象多，Full GC 仍难避免。建议：
- 初始堆（-Xms）与最大堆（-Xmx）设为相同值，避免运行时扩容触发 Full GC
- 年轻代占比控制在 1/3～1/2（如 -XX:NewRatio=2 表示老:新 = 2:1），对短生命周期对象多的应用可提高至 -XX:NewRatio=1
- 使用 -XX:SurvivorRatio 调整 Eden 与 Survivor 区比例（默认 8，即 Eden:S0:S1 = 8:1:1），若对象存活率高，适当增大 Survivor（如 -XX:SurvivorRatio=6）可减少幸存者过早进入老年代
选用合适的垃圾收集器
不同 GC 算法对 Full GC 的触发机制差异很大：
- JDK 8 推荐 -XX:+UseG1GC，G1 通过增量回收和预测模型主动控制老年代回收，能显著降低 Full GC 概率（配合 -XX:MaxGCPauseMillis=200 设置目标停顿）
- JDK 11+ 可考虑 -XX:+UseZGC 或 -XX:+UseShenandoahGC，它们支持并发标记与回收，几乎不触发传统意义的 Full GC
- 避免使用已废弃的 -XX:+UseParallelOldGC 配合 CMS（CMS 在 JDK 14+ 已移除），CMS 失败后会退化为 Serial Old，直接导致 Full GC
控制对象晋升与老年代占用
多数 Full GC 由老年代空间不足或碎片化引发，需从对象行为入手：
立即学习“Java免费学习笔记（深入）”；
- 设置 -XX:MaxTenuringThreshold（如 =15）防止短期对象因阈值过低被误晋升
- 启用 -XX:+AlwaysTenure 会强制所有幸存对象进入老年代，务必禁用；相反，-XX:+NeverTenure（JDK 8 不支持）不可用，应靠阈值+Survivor 容量协同控制
- 监控老年代使用率：若长期高于 70%，说明对象生命周期长或存在内存泄漏，需结合 -XX:+PrintGCDetails -Xloggc:gc.log 分析晋升日志
- 添加 -XX:+UseStringDeduplication（仅 G1）可减少字符串重复对象对老年代的压力
避免显式 GC 与内存泄漏
某些代码行为会直接诱发 Full GC：
- 禁用 -XX:+DisableExplicitGC（推荐），它可屏蔽 System.gc() 调用——很多框架或旧代码中仍存在该调用
- 检查是否存在大对象（≥ 临界值，如 G1 默认 3MB）直接分配到老年代（Humongous Object），可通过 -XX:G1HeapRegionSize 调整区域大小，或优化大集合/缓存的生命周期
- 使用 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path 配合 MAT 分析内存快照，确认是否存在未释放的静态引用、监听器、线程本地变量等泄漏源
调优必须基于真实负载下的 GC 日志反馈，先开启详细日志，再逐项验证效果。没有“万能参数”，只有匹配业务特征的组合。
