我的应用 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 SystemGC

  或者在代码中全局搜索 System.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 的发生，提升应用稳定性和性能。

---