P99飙到2s与FullGC频繁CPU排查

首次归档：2026-09-11 R2 | 难度：进阶

来源文档：interview-2026-09-11.md

原题

场景：

周五下午 3 点，监控告警——核心下单接口 P99 从 150ms 飙到 2s，QPS 不变，CPU 从 30% → 85%，Young GC 从 1 次/分钟 → 5 次/分钟。

问题：

1. 拿到告警后，前 5 分钟按什么顺序排查？
2. CPU 飙高 + GC 频繁，怎么判断是代码问题还是 GC 参数问题？
3. 假设定位到新上线的批量查询方法在循环里频繁创建大对象，怎么修复？

我的回答（2026-09-11）

- 先检查计划任务/外部压力 → 检查线上对象情况 → 看日志 → 排查线上对象创建 - 工具：Arthas、jstack、jmap - 判断逻辑：突然的问题一般是代码问题，不是 GC 参数问题 - 修复：对象栈化处理

点评（2026-09-11）

优点：

• 工具链方向正确（Arthas、jstack、jmap）
• 判断"突然发生=代码问题"这个经验直觉对

不足：

• 排查顺序不够标准（未从监控 → GC 日志 → 线程 → profiler 的路径走）
• 修复方案"对象栈化"表述有误——栈是固定大小，大对象本就应该放堆上
• 未给出具体参数/代码示例

得分：6/10

讲解

问题1：标准排查路径

第1步: 看监控 → 确认CPU和GC指标 → 看GC日志（pause time、heap usage变化）
第2步: 用Arthas的 thread -n 5 或 jstack 看线程阻塞情况
第3步: 看最近代码变更（git log、release记录）
第4步: 用Arthas的 profiler 或 async-profiler 看热点方法

问题2：判断代码 vs GC

问题3：修复方案

• 减少循环内对象创建，用对象池复用
• 用 Stream 优化替代手动循环
• 大对象不应该放栈上（栈固定大小），应在堆上复用或池化
• 验证：对比修复前后的 GC 频率、RT 指标