应用频繁 Full GC 应该如何排查？

排查频繁 Full GC 的思路是：先确认现象，再定位内存去向，最后对症优化。

第一步，收集证据：开启 GC 日志（JDK 9+ 用 -Xlog:gc*），或用 jstat -gcutil 观察老年代占用、FGC 次数和耗时；确认 Full GC 是内存不足触发还是元空间、System.gc()、晋升失败等原因（日志里有触发原因）。

第二步，分析内存：用 jmap -dump 或 -XX:+HeapDumpOnOutOfMemoryError 抓取堆转储，用 MAT/JProfiler 分析支配树，找出占内存最多的对象与引用链。常见根因：内存泄漏（缓存无上限、监听器/ThreadLocal 未清理、连接未关闭）；大对象直接进入老年代；新生代设置过小导致对象过早晋升；元空间不足（大量动态代理、类加载器泄漏）。

第三步，针对处理：泄漏就修代码（给缓存加上限和淘汰、finally/try-with-resources 释放资源）；合理调整堆比例与晋升阈值（-XX:MaxTenuringThreshold）；大堆换 G1/ZGC 降低停顿；元空间问题调整 MaxMetaspaceSize 并排查类加载泄漏。

要点：调参是最后一招，先排除代码问题。可用 Arthas、JMC 在线诊断。追问方向：如何区分内存泄漏与内存溢出？一次完整的线上 OOM 排查流程？

（约 370 字）