一次 OOM 排查（dump文件分析）

一、发现问题

近期 OOM 故障频发，一周内发生了 3 次。

但每次pod重启后，应用又一切正常；上个版本有代码发布的同学，排查了一遍新增代码，没找到可疑之处。

主要现象如下：

1. 群里告警：Grafana 告警，Full GC 次数5分钟内超2次
2. 群里告警：nacos、grpc 等中间件心跳连接超时
3. 集群中对应服务：重启次数新增

Grafana 告警
Alertname: HK-5分钟内GC次数大于2次
状态： 告警
内容：  HK最近10分钟内的FullGC过多，当前值： 75.5，环境：prod，实例：10.20.56.36
应用：  xxxx
时间： 2025-10-13 19:48:51
详情： 告警详情
来源： Grafana 地址

查看 Grafana 中 JVM 问题：

可为什么会导致重启？

看看得：JVM 内部 OOM → 应用假死（线程卡死或频繁 Full GC）→ 健康检查失败 → K8s 重启 Pod

排查此问题困难之处

既然知道是 OOM，那就找对应 OOM 生成 dump 文件，分析即可。

运维侧反馈来不及 dump 文件，就重启了，导致dump文件丢失。

最后，那我又是如何得到这个 dump 文件的？

既然运维侧不给力，那就只能靠平时多观察下这个应用的情况，一有怀疑情况就找对应运维同学。

恰好，被我抓到一次，直接坐到运维同学旁边，让其帮我上容器帮我 dump 一份数据。

二、定位问题

2.1 定位问题：dump 文件分析

生成 dump 文件：找运维同学操作，进入对应 pod 容器中，执行如下命令：

# 1、找到对应 PID：
jps -l

# 2、执行，只想 dump 活跃的对象：
jcmd 12345 GC.heap_dump -all=false /tmp/heap_20240602.hprof

分析工具：使用的是 IDEA 自带的 Profiler

直接打开对应的 dump 文件，展示如下：

可以看到 byte[] 和 byte[][] 数据是 MySQL 里的结果数据：

选择 byte[]：

图中的 GC Root: Java Frame 表示：

• 在 Java 的垃圾回收（GC）机制中，GC Root 是一组特殊的对象引用，它们作为起点，GC 会从这些对象开始遍历引用链，找出所有可达对象。可达的对象不会被回收。
• Java Frame 指的是某个线程的栈帧（方法调用栈）中的局部变量或参数引用了这个对象。

GC Root: Java Frame: com.mysql.cj.protocol.a.NativeProtocol.sendQueryPacket(NativeProtocol.java:951)

这段话意思是：

• 这个 byte[] 对象是被某个线程的栈上的局部变量引用着。
• 具体是在 com.mysql.cj.protocol.a.NativeProtocol 类的 sendQueryPacket 方法（第 951 行）中。
• 因为它在栈上被引用，所以 GC 无法回收它，直到这个方法执行结束并且栈帧被销毁。

找到一个具体的进入看下：

可以定位到某一个 SQL，并将这个 SQL 展示出来。

SELECT amount, currency FROM risk_message

所有的线索都指向这个 SQL 查询带出来大量的数据。

2.2 定位问题：具体代码

通过 SQL 可以缩小范围，所有涉及这个表的代码，主要是 2 个接口：

1. 入账审核列表：getInboundList
2. 汇总-入账成功金额：querySummary —— BUG 点

代码如下：

List<RiskMessage> list = riskMessageRepo.lambdaQuery().select(RiskMessage::getAmount, RiskMessage::getCurrency)
    .eq(StringUtils.isNotBlank(clientId), RiskMessage::getClientId, clientId)
    .in(CollectionUtils.isNotEmpty(currencyList), RiskMessage::getCurrency, currencyList)
    .ge(Objects.nonNull(orderStartTime), RiskMessage::getValueDate, orderStartTime)
    .le(Objects.nonNull(orderEndTime), RiskMessage::getValueDate, orderEndTime)
    .list();

这个功能主要汇总金额，但币种不同，得按照汇率换算出来，他这块实现步骤：

1. 查询出所有符合条件的 <金额、币种> —— 问题点
2. 在内存本地聚合
3. 根据汇率进行换算，得出 USD 币种的金额

问题就在查询这块，没兜住，直接查询出 百万条 记录，导致内存在接下来的 30分钟 逐渐被占满。

1. 时间范围没生效：没有强制时间范围
2. 按币种先汇总：币种只有百来个，返回也只有百来行

直接让 AI 帮我排查这 2 个接口是否有问题：

claude-4-sonnet 回答道：

AI 的回答，居然是没有问题；当再次指出问题时，AI 又站起来了。

三、小结

排查过程中发现的一些事：

1. HTTP 请求调用时间长，不一定造成 OOM，但一定是有问题的。
2. MySQL IN 数量能调节，可以 1w+
3. 现阶段的AI编程，不能完全相信，会绕进一些BUG中，需要人工处理。

最后解决这个问题也比较简单：

1. 强制选定范围
2. 按照币种 SUM，返回行数最多百来行

常见 Full GC 触发原因：