核心内容摘要
提速90%：Zotero文献元数据自动化处理全攻略
发现问题近期 OOM 故障频发一周内发生了 3 次。
但每次pod重启后应用又一切正常上个版本有代码发布的同学排查了一遍新增代码没找到可疑之处。
主要现象如下群里告警Grafana 告警Full GC 次数5分钟内超2次群里告警nacos、grpc 等中间件心跳连接超时集群中对应服务重启次数新增Grafana 告警 Alertname: HK-5分钟内GC次数大于2次 状态 告警❌ 内容 HK最近10分钟内的FullGC过多当前值
7
5环境prod实例
10.
20.
5
36 应用 xxxx 时间
19:48:51 详情 告警详情 来源 Grafana 地址查看 Grafana 中 JVM 问题可为什么会导致重启看看得JVM 内部 OOM → 应用假死线程卡死或频繁 Full GC→ 健康检查失败 → K8s 重启 PodTips另外一种 killOOM Killed PodKubernetes 节点的 Linux 内核 OOM Killer 杀掉了 Pod 进程可能是 JVM 进程通常是容器的内存限制被突破。
排查此问题困难之处既然知道是 OOM那就找对应 OOM 生成 dump 文件分析即可。
运维侧反馈来不及 dump 文件就重启了导致dump文件丢失。
最后那我又是如何得到这个 dump 文件的既然运维侧不给力那就只能靠平时多观察下这个应用的情况一有怀疑情况就找对应运维同学。
恰好被我抓到一次直接坐到运维同学旁边让其帮我上容器帮我 dump 一份数据。
定位问题
1 定位问题dump 文件分析生成 dump 文件找运维同学操作进入对应 pod 容器中执行如下命令#
找到对应 PID jps -l #
执行只想 dump 活跃的对象 jcmd 12345 GC.heap_dump -allfalse /tmp/heap_
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:
这段话意思是这个byte[]对象是被某个线程的栈上的局部变量引用着。
具体是在com.mysql.cj.protocol.a.NativeProtocol类的sendQueryPacket方法第 951 行中。
因为它在栈上被引用所以 GC 无法回收它直到这个方法执行结束并且栈帧被销毁。
找到一个具体的进入看下可以定位到某一个 SQL并将这个 SQL 展示出来。
SELECT amount, currency FROM risk_message所有的线索都指向这个 SQL 查询带出来大量的数据。
2 定位问题具体代码通过 SQL 可以缩小范围所有涉及这个表的代码主要是 2 个接口入账审核列表getInboundList汇总-入账成功金额querySummary—— BUG 点代码如下ListRiskMessage 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();这个功能主要汇总金额但币种不同得按照汇率换算出来他这块实现步骤查询出所有符合条件的 金额、币种 —— 问题点在内存本地聚合根据汇率进行换算得出 USD 币种的金额问题就在查询这块没兜住直接查询出 百万条 记录导致内存在接下来的 30分钟 逐渐被占满。
时间范围没生效没有强制时间范围按币种先汇总币种只有百来个返回也只有百来行直接让 AI 帮我排查这 2 个接口是否有问题claude-4-sonnet 回答道AI 的回答居然是没有问题当再次指出问题时AI 又站起来了。
小结排查过程中发现的一些事HTTP 请求调用时间长不一定造成 OOM但一定是有问题的。
MySQL IN 数量能调节可以 1w现阶段的AI编程不能完全相信会绕进一些BUG中需要人工处理。
最后解决这个问题也比较简单强制选定范围按照币种 SUM返回行数最多百来行常见 Full GC 触发原因触发原因说明典型特征排查方法老年代空间不足大对象直接进入老年代或晋升失败GC 日志显示 Allocation Failure老年代使用率接近 100%查看 GC 日志中 Old Gen 使用率分析对象生命周期元空间Metaspace不足类加载过多动态生成类如反射、CGLIBGC 日志显示 Metadata GC Threshold-XX:MaxMetaspaceSize 设置过小或类加载泄漏显式调用 System.gc()代码或第三方库调用GC 日志显示 System.gc()GC 日志会显示 System.gc() 触发直接内存不足DirectByteBuffer / Netty 堆外内存耗尽堆外内存不足时 JVM 会频繁 Full GC 尝试释放 Cleaner-XX:MaxDirectMemorySize用 jcmd VM.native_memory summary 查看大对象分配失败超过 PretenureSizeThreshold 直接进老年代GC 日志显示 Promotion failed调整阈值或优化对象分配CMS/G1 的 remark 阶段失败并发回收失败退化为 Full GCGC 日志显示 concurrent mode failure 或 to-space exhausted查看 GC 日志的 concurrent mode failure 或 to-space exhausted