源自AI解答记录下来我的sprintboot程序服务疯狂full gc接口超时告警刷屏怎么排查说一下步骤以及命令 第一阶段紧急“体检” (确认 GC 状态)首先你需要确认当前 JVM 的内存是不是真的满了以及 Full GC 的频率。1. 找到进程 ID (PID)jps -l # 或者 ps -ef | grep java2. 实时监控 GC 情况 (jstat)这是最快判断问题的方法。使用jstat每秒刷新一次 GC 状态# 语法: jstat -gcutil PID 刷新间隔ms 刷新次数 jstat -gcutil PID 1000 10重点看这几列O (Old Gen):老年代使用率。如果一直维持在90%~100%说明老年代满了。FGC (Full GC Count):Full GC 次数。如果这个数字在几秒钟内疯狂上涨说明确实陷入了“死循环”。FGCT (Full GC Time):Full GC 总耗时。判断标准如果O接近 100%且FGC飞速增加说明系统正在频繁进行 Full GC 且回收效果极差几乎回收不动这通常是内存泄漏的铁证。️ 第二阶段寻找“凶手” (定位内存泄漏)如果确认是内存泄漏你需要知道是谁占用了内存。1. 快速查看对象直方图 (jmap -histo)不需要 Dump 整个堆先看哪种类型的对象数量最多。# 查看存活对象的直方图按大小排序取前20行 jmap -histo:live PID | head -20分析看看排在前面的类名class name。如果是byte[]、String或者你业务中的某个实体类如Order,User数量异常巨大那它就是嫌疑人。2. 导出堆快照 (jmap -dump)这是最核心的步骤。将内存中的对象 dump 出来用专业工具分析。# 导出堆内存文件 (文件可能很大注意磁盘空间) jmap -dump:live,formatb,file/tmp/dump.hprof PID注意执行此命令时 JVM 会暂停服务一小会儿但在 Full GC 频繁时影响相对较小因为服务本来就卡。3. 检查 JVM 启动参数 (jinfo)确认是不是堆内存设置得太小或者参数配置不合理。jinfo -flags PID检查-Xms(初始堆) 和-Xmx(最大堆) 是否一致。如果不一致JVM 会不断调整堆大小也会触发 GC。️ 第三阶段深度“解剖” (分析 Dump 文件)将上一步生成的dump.hprof文件下载到本地使用Eclipse MAT (Memory Analyzer Tool)或JProfiler打开。分析步骤Leak Suspects Report (内存泄漏嫌疑报告):MAT 会自动生成一个报告直接指出哪个对象占用了大部分内存通常是一个大饼图。Dominator Tree (支配树):查看占用内存最大的对象。Path To GC Roots (引用链分析):右键点击可疑对象 -Merge Shortest Paths to GC Roots。目的找出是谁在引用这个对象导致它无法被回收。常见原因静态集合static Map/List只 put 不 remove。ThreadLocal线程池中的 ThreadLocal 没清理。缓存未清理本地缓存如 Guava/Caffeine没有设置过期时间或大小限制。 第四阶段复盘与验证 (GC 日志)如果条件允许或者为了下次预防必须开启 GC 日志。这是“黑匣子”。1. 开启 GC 日志 (启动参数)-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.log2. 分析日志查看 Full GC 前后的内存变化[Full GC ... [PSYoungGen: ...] [ParOldGen: 800M-799M(1000M)] ...]如果 Full GC 后老年代内存ParOldGen从 800M 变成 799M说明只回收了 1M回收效率极低再次确认是内存泄漏。 总结排查命令速查表表格步骤目的命令关键指标1看状态jstat -gcutil PID 1000O(老年代使用率),FGC(次数)2看对象jmap -histo:live PID | head -20哪种 Class 实例数量最多3抓现场jmap -dump:live,filedump.hprof PID生成文件用于 MAT 分析4看配置jinfo -flags PID-Xms,-Xmx5看线程jstack PID确认是否有死锁或线程阻塞 紧急恢复建议如果服务已经不可用且无法立即定位代码问题重启服务暂时恢复业务但这治标不治本内存 leak 还会复现。保留现场重启前务必先执行jmap -dump保存堆快照否则重启后证据就没了。临时扩容如果是堆内存确实太小如几百兆可以尝试调大-Xmx争取缓冲时间。