Java Full GC 频繁告警怎么处理：堆内存、降级和回滚值班手册

Java 服务突然频繁 Full GC，值班时最棘手的场景就是两头堵：一边停顿时间越来越长，接口错误跟着一路上涨；另一边不少人着急改堆参数或是直接重启，反倒把真正的对象增长证据直接冲没。更稳妥的处理顺序是先核实影响范围，再抓取堆和线程的现场数据，通过临时降级压住入口流量，最后结合最近的发布记录、缓存策略调整或是批任务变动，判断是回滚还是针对性修复代码。

告警响起后先判断业务是否已经受影响

Full GC 本身不算事故，真正出问题往往是它连带引发请求停顿、超时，最后拉高整体错误率。值班台上看到 `Full GC Count` 快速增长时，先把 JVM 指标和业务指标放到同一个时间窗口里对照：如果停顿峰值超过接口超时时间的一半，或者错误率、排队时间同步上升，就要按线上故障标准流程处理。

这时候别急着修改参数。很多服务的 Full GC 是某次缓存策略调整、批量导入、报表导出或者大对象拼接逻辑触发的，单纯扩大堆内存只会让下一次 Full GC 的停顿时间更长。更可靠的第一步是把关键信号先固定留存下来。

快速抓证据：保留堆、线程和 GC 现场

抓取证据不用覆盖所有实例。先选告警特征最明显的那台机器，记录下进程号、实例名、对应时间窗和最近发布的版本号。生产环境执行的命令要简洁、操作要轻量，避免在业务高峰对所有实例同时执行 heavy 操作放大影响。

# 找到 Java 进程，确认服务名和进程号
jcmd | grep order-service

# 查看堆基本情况
jcmd 18342 GC.heap_info

# 连续观察 GC 使用率，每 1 秒采样 10 次
jstat -gcutil 18342 1000 10

# 抓一份对象直方图，先看哪些类占用靠前
jcmd 18342 GC.class_histogram > /tmp/order-service-histo.txt

# 抓线程快照，配合请求堆积和锁等待判断
jstack -l 18342 > /tmp/order-service-thread.txt

如果需要生成完整堆快照，尽量在已经降级或者已经摘流的实例上操作，导出的文件要写入磁盘空间充足的存储路径。线上排查常见的误区是只看一次堆直方图就下结论，实际更建议间隔几分钟抓取两份数据，对比同一类对象的数量是否在持续增长。

处理动作按风险从低到高推进

Full GC 已经影响用户时，先把系统从“持续恶化”的状态拉回“可稳定观察”的状态。低风险动作通常包括关闭非核心入口、降低批任务并发数、暂停大报表导出任务、临时缩短缓存保留时间、把高耗时接口切到降级返回逻辑。只要能把对象分配速度压下来，GC 停顿往往会先得到缓解。

如果告警紧接在一次发布之后，而且这次发布调整过缓存、集合聚合、批量查询或者 JSON 组装相关逻辑，直接回滚比现场猜参数调整要稳妥得多。尤其是 Full GC 执行后老年代占用仍然没有明显下降，说明堆里有对象被强引用牢牢留住，继续放大 `-Xmx` 参数只能把爆点延后，没法解决根本问题。

回滚后用三个结果确认服务恢复

回滚操作完成不代表问题已经处理完。先看 GC 停顿峰值是否回落，再看老年代使用曲线是否回到往常的稳定区间，最后看接口超时和网关错误率是否同步下降。三条指标线都恢复到正常水平，才能把事故从处置阶段切到复盘阶段。

# 回滚后继续采样，确认老年代和停顿趋势
jstat -gcutil 18342 1000 20

# 对比回滚前后的对象直方图前 30 行
head -30 /tmp/order-service-histo-before.txt
head -30 /tmp/order-service-histo-after.txt

如果回滚后业务错误已经恢复，但老年代占用仍然很高，说明堆里还有存量对象没有释放。这时候可以单独摘掉一台实例做更深入的堆分析，再决定是否分批重启剩余实例。不要直接全量重启，把整个服务的可用性赌在服务启动速度上。

复盘时重点定位对象为什么长期留在堆里

Java Full GC 的复盘结论不该只写“内存不足”这类空泛的描述。更有价值的结论是定位出对象一直留在堆里的具体原因：比如缓存没有设置最大容量、静态 Map 一直在追加数据、异步结果列表没有做清理、一次性批量查询返回过多行、日志上下文没有及时释放，或者某个定时任务把大量历史数据攒在内存里。

• 缓存类问题：检查最大容量、过期策略、key 粒度和热 key 是否出现异常膨胀。
• 集合类问题：检查 `List`、`Map` 是否跨请求复用，是否被静态字段或单例对象长期持有。
• 批任务问题：检查分页大小、临时对象生成数量、导出文件是否改为流式写出。
• 请求类问题：检查大 JSON、图片字节数组、长字符串拼接逻辑是否被一次性全部加载进内存。
• 线程类问题：检查线程本地变量、请求上下文和连接对象是否跟着对应生命周期做清理。

复盘记录里还要补充“下次怎么更早发现异常”的优化动作：比如老年代占用连续 5 分钟超过 80% 才告警的规则太滞后，可以新增 Full GC 频率、最大停顿时间、堆内存增长斜率和实例错误率的组合告警规则。组合告警比单一阈值告警更贴近真实业务影响。

常见问题

Java Full GC 一定是内存泄漏吗？

不一定。它也可能是瞬时分配峰值过高、批任务配置过大、堆设置偏小或者缓存策略不合理导致的。只有 Full GC 执行后老年代占用仍没有明显下降，才更需要排查对象被长期引用的泄漏场景。

能不能先把堆参数调大？

可以作为临时缓冲手段，但不应该是第一选择。堆内存变大后，下一次 Full GC 的停顿时间可能会更长；没提前抓取证据就直接调大堆参数，还会掩盖真正的对象增长来源，拖慢后续排查进度。

抓堆快照会不会影响线上服务？

确实存在风险，尤其是堆内存很大、磁盘紧张或者实例正处于业务高峰承压的阶段。更稳妥的做法是先对单台实例做摘流或者降级操作，再在这台问题实例上抓取快照，同时提前确认目标存储路径的剩余空间足够。

回滚后还需要继续分析吗？

需要。回滚只是完成了临时止血，复盘环节要找出对象增长的完整路径、原有告警为什么没有更早触发、下次是否能通过限流或者灰度机制提前挡住影响范围。

GC 日志和对象直方图哪个更重要？

两者的用途不一样。GC 日志会记录什么时候触发停顿、停顿了多久、回收效果如何；对象直方图能帮你快速定位哪几类对象的占用占比最高。实际排查时通常要把两份数据结合起来分析。

处理清单

遇到 Java Full GC 频繁告警，先确认业务影响，再留存 JVM 现场数据；先走降级止血流程，再判断是否需要执行回滚；服务恢复后用 GC 指标、堆占用指标和业务错误率三组结果交叉验证恢复状态。最后把对象保留链、缓存上限、批任务分页规则和组合告警规则的优化补进复盘记录，这样下次再遇到同类告警，就不会只剩“重启试试”这一个处理选项。