Java应用频繁Full GC是系统报警信号，需按“确认现象→分析GC日志→抓取堆快照→验证根因”四步定位内存泄漏或对象堆积，而非盲目调参。
Java 应用频繁 Full GC 不是性能波动，而是系统在报警——它意味着老年代持续承压、对象回收失效，甚至已开始影响可用性。关键不是“怎么调参数”，而是“先确认问题类型、再锁定根因”。下面按实战节奏分步说明。
一、先确认：是不是真在频繁 Full GC？
别急着看堆 dump 或改 JVM 参数，先用最轻量方式验证现象是否属实：
- jstat -gc <pid> 1000 10：每秒输出一次 GC 统计，连看 10 秒。重点关注 FGC（Full GC 次数） 是否持续上涨；若每分钟 ≥1 次，即属严重异常
-
GC 日志中搜索 “Full GC” 或 “(System)”：确认是否由显式
System.gc()触发；同时留意日志末尾的触发原因，如Allocation Failure（老年代空间不足）、Metaspace（元空间满）、Concurrent Mode Failure（CMS 收集器特有） -
观察老年代使用率趋势：用
jstat -gcutil看 O（Old）列，若 GC 后仍长期 >85%，且回收量极小（比如只降 1%～2%），基本可判定存在内存泄漏或大对象堆积
二、查日志：从 GC 日志定位触发根源
GC 日志是唯一能还原每次回收“为什么发生”的原始证据。确保生产环境已开启（JDK8+ 推荐）：
-
启动参数示例：
-Xlog:gc*:file=/var/log/app/gc.log:time,uptime:filecount=10,filesize=10M -
重点分析三类线索：
- 日志中出现
java.lang.OutOfMemoryError: Metaspace→ 元空间溢出，大概率是类加载器泄漏或动态生成类过多（如大量 Groovy 脚本、反复 redeploy） - 连续多次 Full GC 后
Old区几乎不下降 → 对象无法被回收，指向内存泄漏 - 每次 Full GC 前都有大块对象分配失败（
promotion failed或to-space overflow）→ 新生代对象晋升失败，常因 Survivor 区太小或对象存活时间过长
- 日志中出现
三、抓快照：用堆转储定位“谁占了老年代”
当确认是内存泄漏或对象堆积时，必须拿到堆现场证据：
立即学习“Java免费学习笔记（深入）”；
-
触发 dump：
jmap -dump:live,format=b,file=heap.hprof <pid>（加live只导出可达对象，更准） -
快速初筛（不用下载大文件）：
jmap -histo:live <pid>查看前 20 名对象数量及总大小，重点关注：[B（byte[]）、[I（int[]）、java.util.HashMap$Node、java.lang.Class、自定义大对象类名 - 深度分析（推荐 MAT）：用 Eclipse MAT 打开 hprof 文件，运行 Leak Suspects Report；再看 Dominator Tree，找 Retained Heap 最大的对象及其 GC Roots 引用链 —— 这就是泄漏源头
四、对常见根因做针对性验证
不必穷举所有可能，聚焦高频场景，逐项排除：
-
静态集合缓存未清理：搜代码中
static Map/Map/Cache，检查是否有 put 无 remove、无过期策略、未用 WeakReference -
ThreadLocal 泄漏：尤其在线程池场景下，检查是否每个请求都 new ThreadLocal 实例却没调
remove()；MAT 中看java.lang.ThreadLocal$ThreadLocalMap是否持有大量业务对象 -
大对象直入老年代：查日志中是否频繁出现
Humongous Allocation（G1）或direct to old gen；代码中排查超大 byte[]、StringBuilder、JSON 字符串拼接、未分页的 List 查询结果 - 连接类资源未释放：数据库连接、Redis 客户端、HTTP 连接池（OkHttp/HttpClient）是否复用不当、未 close、未配置最大空闲数
不复杂但容易忽略：多数 Full GC 风暴不是配置问题，而是某段代码悄悄把对象钉在了老年代。先让现象说话，再让日志指路，最后让堆快照定罪——这个顺序走稳了，90% 的问题都能在 30 分钟内定位到具体类和方法。
