出现FullGC的排查思路

一、明确Full GC的触发原因

根据多篇资料，Full GC的触发条件主要包括：

1. 直接调用System.gc()：代码或第三方库（如jxl组件）可能显式触发。
2. 老年代空间不足：大对象直接进入老年代、Minor GC后存活对象过多导致晋升失败、动态年龄判断机制等。
3. 元空间（方法区）不足：类加载过多或反射调用频繁导致元空间占满。
4. 空间分配担保失败：Minor GC时预估晋升老年代的对象大小超过老年代剩余空间。
5. CMS GC并发模式失败：CMS回收过程中老年代空间不足以分配新对象。

---

二、排查与解决步骤

1. 检查是否显式调用System.gc()

• 代码审查：排查代码中是否直接调用System.gc()，尤其是批量处理、Excel操作（如jxl组件）等场景。
• 日志分析：通过GC日志确认触发原因，例如日志中若出现Full GC (System.gc())则可定位问题。
• 解决方案：注释相关代码，或添加JVM参数-XX:+DisableExplicitGC禁用显式调用。

2. 分析GC日志与监控数据

• 监控工具：使用jstat -gc观察GC频率、老年代占用率及晋升情况。
• 日志关键信息：
  • 若老年代占用率在Full GC后仍接近100%，说明存在内存泄漏或对象未释放。
  • 若元空间占用持续增长，需检查类加载情况（如动态生成类、大量反射）。
• 示例场景：某案例中，老年代因List<Map>存储Excel数据导致频繁Full GC，最终通过改用缓存或优化数据结构解决。

3. 检查大对象与内存泄漏

• 大对象识别：通过jmap -histo或内存快照（jmap -dump）分析堆中占用较大的对象。
• 常见问题：
  • 静态集合未清理：如static Map缓存未设置过期机制。
  • 线程局部变量泄漏：如ThreadLocal未及时remove()。
  • 第三方库缺陷：如POI操作Excel时未限制行数，生成大量Row对象。
• 解决方案：优化代码逻辑，避免长期持有大对象；改用更高效的数据结构（如数组替代HashMap）。

4. 检查元空间与类加载

• 元空间监控：通过jstat -gc观察MC（元空间提交量）和MU（元空间使用量）。
• 类加载问题：频繁加载新类（如动态代理、Groovy脚本）可能导致元空间占满。
• 解决方案：调整元空间大小（-XX:MetaspaceSize），或优化代码减少类加载。

5. 调整JVM参数（治标）

• 老年代扩容：增大-Xmx（堆最大值）和-Xms（堆初始值），避免频繁晋升失败。
• 优化GC策略：如使用G1垃圾回收器替代CMS，减少STW时间。
• 元空间限制：设置-XX:MaxMetaspaceSize防止无限膨胀。

6. 根因分析与业务优化（治本）

• 业务逻辑优化：例如分页查询避免全表扫描导致内存溢出。
• 架构调整：将大对象存储到外部缓存（如Redis）而非JVM堆。
• 流量控制：针对业务高峰期的突发请求，增加限流或异步处理机制。

---

三、总结回答模板

1. 定位原因：首先通过GC日志和监控工具（如jstat、jmap）确认Full GC触发场景（如老年代不足、显式调用等）。
2. 代码审查：排查显式GC调用、大对象创建、静态集合未清理等代码问题。
3. 内存分析：生成堆快照，使用MAT或JProfiler分析大对象及内存泄漏。
4. 参数调整：根据场景调整堆大小、元空间限制或GC算法（如G1）。
5. 业务优化：从设计层面避免内存瓶颈，如分库分表、缓存分离。

关键点：Full GC多数由代码问题引起，需优先排查业务逻辑，而非盲目调整JVM参数。