我的应用 Full GC 频繁，怎么优化？
你的应用出现 Full GC 频繁，这是一个典型的 性能问题，通常会导致应用出现明显的 卡顿（停顿时间长，即 Stop-The-World），甚至影响服务的可用性与吞吐量。
要解决 Full GC 频繁 的问题，首先需要理解 为什么会发生 Full GC，然后通过 监控、分析、调优 一步步定位和解决问题。
一、什么是 Full GC？
Full GC（Full Garbage Collection） 是指对 整个 Java 堆（新生代 + 老年代）以及方法区（或元空间 Metaspace） 进行垃圾回收。它几乎会扫描所有内存区域，通常伴随长时间的 Stop-The-World（STW），对应用性能影响非常大。
二、Full GC 频繁的常见原因
下面是导致 Full GC 频繁的 最常见原因，我们逐一分析：
✅ 1. 老年代空间不足
原因：
- 新生代对象经过 Minor GC 后仍然存活，需要晋升到老年代；
- 如果 老年代没有足够的连续空间容纳这些对象，就会触发 Full GC 来尝试释放空间。
典型场景：
- 大量生命周期较长的对象不断累积；
- 剩余老年代空间太小，或者存在内存碎片，导致无法分配。
解决方法：
- 增大老年代空间：调整
-Xmx（最大堆）、-Xms（初始堆）、-Xmn（新生代大小），适当增加老年代比例； - 避免短命大对象直接进入老年代：调整
-XX:PretenureSizeThreshold； - 优化代码，减少长生命周期对象的创建和驻留。
✅ 2. 永久代 / 元空间（Metaspace）不足（JDK 8 之前是 PermGen，之后是 Metaspace）
原因：
- 在 JDK 7 及之前，如果 加载的类元信息、常量池、静态变量太多，超出 PermGen 空间，会触发 Full GC；
- 在 JDK 8 及以后，PermGen 被移除，改为 Metaspace，默认不限制大小（受物理内存限制），但如果 Metaspace 空间不足，也会触发 Full GC（或 OutOfMemoryError: Metaspace）。
解决方法：
- JDK 7 及之前： 增大 PermGen：
-XX:MaxPermSize=256m - JDK 8 及之后： 增大 Metaspace：
-XX:MaxMetaspaceSize=256m（根据实际情况调整） - 检查是否有大量的动态类生成（如反射、动态代理、CGLIB、热部署等），优化相关代码逻辑。
✅ 3. 显式调用 System.gc()
原因：
- 代码中 显式调用了
System.gc()，会建议 JVM 执行一次 Full GC（虽然不保证立刻执行，但很多 JVM 配置下会遵从）； - 如果频繁调用，将导致频繁 Full GC。
解决方法：
- 查找代码中是否有 System.gc() 的调用，使用如下命令查看：
或者在代码中全局搜索jcmd <pid> VM.flags | grep SystemGCSystem.gc()； - 添加 JVM 参数禁止 GC 建议生效：
-XX:+DisableExplicitGC注意：某些框架（如 NIO 的 DirectByteBuffer、RMI 等）可能仍会间接触发 GC，需综合考虑。
✅ 4. 空间分配担保失败（Promotion Failure）
原因：
- 在 Minor GC 时，Survivor 区无法容纳所有存活对象，需要将这些对象直接晋升到老年代；
- 但如果 老年代也没有足够的连续空间来容纳它们，就会触发一次 Full GC 来腾出空间 —— 这叫做 “分配担保失败”。
解决方法：
- 增大新生代空间（-Xmn）或老年代空间，让更多对象留在新生代；
- 合理设置对象晋升年龄阈值（-XX:MaxTenuringThreshold），避免对象过早进入老年代；
- 监控 Survivor 区使用情况，避免频繁溢出。
✅ 5. 内存泄漏（Memory Leak）
原因：
- 应用中存在 某些对象本应该被回收，但由于被错误地持有引用（如静态集合、未关闭的资源、监听器未注销等），导致这些对象无法回收，不断累积在老年代，最终占满老年代，触发 Full GC。
典型例子：
- 静态 Map/List 持续添加对象却从不清理；
- 缓存未设置上限或过期策略；
- 监听器、回调未正确注销；
- 线程池未正确关闭，线程持有对象引用。
解决方法：
- 使用内存分析工具排查，如：
- MAT（Eclipse Memory Analyzer）
- VisualVM
- JProfiler
- Jmap + Jhat / JVisualVM
- 分析 堆转储文件（Heap Dump），查找哪些对象占用了大量内存且无法回收；
- 修复代码中的不合理引用、缓存策略、资源释放等问题。
✅ 6. 垃圾收集器选择不当 或 配置不合理
原因：
- 某些垃圾收集器（如 CMS）在特定情况下（如并发模式失败、空间碎片化）会触发 Full GC；
- 如果使用的是 Serial Old、Parallel Old 等收集器，Full GC 的代价更高、更频繁。
解决方法：
- 根据应用特点选择合适的垃圾收集器，比如：
- 低延迟场景：考虑 G1（JDK9+ 默认）、ZGC、Shenandoah；
- 高吞吐量场景：Parallel GC；
- Web 应用、微服务：G1 是目前主流推荐。
- 调整 GC 参数，比如使用 G1 后可以避免很多传统 Full GC 问题：
-XX:+UseG1GC
三、排查 Full GC 频繁问题的步骤（实操指南）
第一步：确认 Full GC 是否频繁
使用以下命令查看 GC 情况：
jstat -gcutil <pid> 1000 10
- 观察 FGC（Full GC Count）和 FGCT（Full GC Time），如果 FGC 数值在短时间内快速增加，说明 Full GC 频繁。
或者查看 GC 日志（强烈推荐）：
第二步：开启 GC 详细日志
在 JVM 启动参数中加入：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log
分析 gc.log 文件，查找关键字：
[Full GC或[Full GC (Allocation Failure)等- 观察 Full GC 的触发原因、频率、耗时
推荐使用工具分析 gc.log，如 GCViewer、GCEasy、HP JMeter、阿里Arthas等
第三步：dump 堆内存，分析内存使用情况（排查内存泄漏）
使用如下命令生成 Heap Dump：
jmap -dump:format=b,file=heap.hprof <pid>
然后用如下工具分析：
- Eclipse MAT（Memory Analyzer Tool）
- VisualVM
- JProfiler
- YourKit
查找：
- 哪些对象占用了大量内存
- 哪些对象仍然存活但本应被回收 → 内存泄漏嫌疑对象
四、优化建议总结（Checklist ✅）
| 问题类型 | 解决方案 |
|---|---|
| 老年代空间不足 | 增大堆内存（-Xmx）、合理分配新生代与老年代（-Xmn）、优化对象生命周期 |
| 元空间/永久代不足 | 增加 -XX:MaxMetaspaceSize 或 -XX:MaxPermSize |
| 显式调用 System.gc() | 搜索代码并删除，或添加 -XX:+DisableExplicitGC |
| 分配担保失败 | 增大新生代或老年代，调整晋升年龄 -XX:MaxTenuringThreshold |
| 内存泄漏 | 使用 MAT / VisualVM 分析堆转储，修复不合理引用 |
| GC 收集器不合适 | 考虑切换到 G1（-XX:+UseG1GC）、ZGC 等现代收集器 |
| Survivor 区不足 / 对象晋升过快 | 调整 -Xmn、-XX:SurvivorRatio、-XX:MaxTenuringThreshold |
五、推荐垃圾收集器（针对 Full GC 优化）
| 收集器 | 适用场景 | 是否避免 Full GC | 备注 |
|---|---|---|---|
| G1 GC | 中大型应用，低延迟 & 高吞吐 | ✅ 大幅减少 Full GC | JDK9+ 默认，推荐使用 |
| ZGC / Shenandoah | 超大堆、超低延迟需求 | ✅ 几乎无 Full GC | JDK11+ / 12+ 实验或生产可用 |
| CMS | 老年代低停顿（已废弃） | ❌ 可能并发失败触发 Full GC | JDK14 移除 |
| Parallel GC | 高吞吐量后台任务 | ❌ 传统 Full GC | 适用于批处理等 |
推荐： 生产环境尽量使用 G1 GC，在 JDK 9+ 是默认收集器，对 Full GC 有很好的控制与优化。
启动参数示例：
-XX:+UseG1GC
-Xms4g -Xmx4g
-XX:MaxGCPauseMillis=200
✅ 总结一句话：
Full GC 频繁通常是由于老年代空间不足、内存泄漏、配置不当或 GC 策略不合理导致的。通过开启 GC 日志、分析内存使用、优化对象生命周期和选择合适的垃圾收集器，可以有效减少甚至避免 Full GC 的发生，提升应用稳定性和性能。