1. 从现象到本质：FullGC频繁触发的典型表现
最近在排查线上Java应用性能问题时，发现一个有趣的现象：应用发布新版本后，FullGC次数突然从日均个位数飙升到每小时20+次。虽然暂时没有引发严重故障，但作为有经验的开发者都知道，频繁FullGC就像定时炸弹，必须及时排查。
先说说我是怎么发现问题的。当时正在做常规的监控巡检，突然发现GC监控面板上出现了一连串的红色标记（我们监控系统用红色表示FullGC）。通过对比发布时间线，可以确定是新版本引入的问题。这里分享一个实用技巧：建议所有Java应用都配置GC日志和实时监控，我常用的基础监控命令是：
jstat -gcutil <pid> 1000这个命令每秒输出一次内存分区使用率和GC统计，关键指标包括：
- E：Eden区使用率
- O：老年代使用率
- YGC/YGCT：YoungGC次数和耗时
- FGC/FGCT：FullGC次数和耗时
当时观察到一个反常现象：每次FullGC后，老年代内存（O列）几乎没有变化，而新生代（E列）却被完全清空。这排除了老年代内存不足的常见原因，暗示可能是System.gc()显式调用或元空间问题导致的。
2. 双管齐下：jstat实时监控与GC日志分析的配合技巧
2.1 jstat动态监控实战
jstat就像Java内存系统的听诊器，能实时反映内存变化。我通常会在问题排查时开两个终端：
- 一个持续运行
jstat -gcutil观察整体趋势 - 另一个用
jstat -gc <pid> 1s查看详细内存变化
这里有个排查FullGC的经典模式：当发现FGC次数异常增长时，立即用以下命令抓取详细数据：
# 每200毫秒采样一次，输出20次 jstat -gc <pid> 200ms 20 > gc_monitor.log通过分析这些数据，我发现每次FullGC都伴随着YoungGC（YGC计数同步增加），但老年代占用始终稳定在70%左右。这验证了之前的猜想——不是常规的内存泄漏问题。
2.2 GC日志深度分析配置
光靠jstat还不够，需要开启详细GC日志记录。推荐的生产环境配置：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M这些参数会生成包含时间戳的详细GC日志，并自动轮转防止磁盘爆满。最近发现一个超好用的GC日志分析工具GCeasy（在线免费版就够用），上传日志文件后会自动生成可视化报告：
- 堆内存趋势图：一眼看出内存泄漏
- GC原因统计：区分System.gc()与内存不足触发
- 暂停时间分布：发现长暂停异常点
在我的案例中，报告明确显示98%的FullGC都是由System.gc()触发，而非内存压力。这直接锁定了排查方向。
3. 定位元凶：如何揪出隐藏的System.gc()调用
3.1 Arthas神器实战
知道是System.gc()的问题后，接下来要找到调用源头。这里推荐阿里开源的Arthas，它可以在不重启应用的情况下进行方法调用追踪。具体操作步骤：
# 下载并启动Arthas curl -O https://arthas.aliyun.com/arthas-boot.jar java -jar arthas-boot.jar # 在Arthas控制台中执行 options unsafe true # 开启不安全命令权限 stack java.lang.System gc # 监控gc方法调用这个命令会挂起等待，当System.gc()被调用时，会打印完整的调用栈。在我的案例中，发现是日期工具类中的异常处理块调用了System.gc()：
// 问题代码示例 public static Date parseDate(String str) { try { return new SimpleDateFormat().parse(str); } catch (Exception e) { System.gc(); // 坑爹的调用 return null; } }3.2 调用链分析技巧
通过Arthas输出的调用栈，发现这个工具类被用在循环处理业务数据的场景。这就解释了为什么System.gc()调用次数（300+）远高于实际FullGC次数（198次）——部分连续调用被JVM合并处理了。
这里分享一个排查经验：当看到System.gc()调用次数与FullGC次数不成比例时，很可能是高频调用场景。可以用Arthas的tt命令记录方法调用上下文：
# 记录最近5次System.gc()调用的完整上下文 tt -t java.lang.System gc -n 54. 根治方案：从临时修复到长效机制
4.1 立即补救措施
定位到问题后，我们采取了三个紧急措施：
禁用显式GC（风险提示：确保没有依赖System.gc()的关键功能）：
-XX:+DisableExplicitGC优化问题工具类：移除catch块中的System.gc()调用
增加监控告警：对FullGC频率设置每分钟阈值告警
4.2 长期预防机制
为了避免类似问题，我们建立了代码审查清单：
- 禁止在业务代码中直接调用System.gc()
- 工具类异常处理禁止包含GC操作
- 新增JVM参数监控看板，包含：
jstat -gcutil <pid> 30000 # 每30秒采集 jcmd <pid> VM.flags | grep GC # 检查GC相关参数
5. 进阶排查：当常规方法失效时的备选方案
有时候问题没那么简单。曾遇到过一个案例：禁用显式GC后FullGC仍然频繁，最后发现是元空间动态类加载导致的。这类问题需要更高级的工具：
MAT内存分析：
jmap -dump:live,format=b,file=heap.hprof <pid>JFR飞行记录：
jcmd <pid> JFR.start duration=60s filename=recording.jfrNative内存追踪（适合元空间问题）：
-XX:NativeMemoryTracking=detail jcmd <pid> VM.native_memory detail
记住一个原则：当GC问题难以复现时，JFR是最佳选择，它能记录完整的事件流，包括安全点、类加载等关键信息。
这次排查经历让我深刻体会到，好的工具组合比单一工具强大得多。jstat提供实时视角，GC日志给出历史记录，Arthas实现动态诊断，三者配合使用能解决大多数GC问题。关键是要建立系统的排查思路：从现象到数据，从数据到根因，最后给出针对性的解决方案。
