2021-11-14

生产环境 JVM 内存溢出引发思考

---

前言

发生内存泄露，通常情况下是由于代码的原因造成的，一般无法立即对代码进行修复，很容易会发送连锁反应造成应用服务器一台一台接连宕机，故障面积会慢慢扩大，针对此种情况，应快速定位发生内存泄露的原因，将该服务进行降级，避免对其他服务造成影响。最简单的降级方法是根据 F5(Nginx)转发策略，对该功能定向到一个单独的集群，与其他流量进行隔离，确保其他业务不受牵连，给故障排查、解决提供宝贵的缓冲时间。

---

一、分析问题

首先可以通过查看日志，确定是哪种内存溢出，堆内存溢出可发生的地方：Java heap space(堆空间)、perm space(持久代)。

二、收集内存溢出Dump文件

1.收集dump文件

设置 JVM 启动参数

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/opt/jvmdump

使用 jmap 命令收集

jmap -dump:live,format=b,file=/opt/jvm/dump.hprof pid。

2.分析 Dump 文件

在获取 Dump 文件后，可以使用工具 MAT(MemoryAnalyzer)进行分析。


可以明确，堆的总大小为 1.9G，被 4 个线程全部占据，导致其他线程无法再申请资源，抛出堆内存溢出错误。
接下来，我通常的做法是直接去看【内存使用树状结构，见上文描述】(以线程为基本维度，查找线程中占用内存的对象)，为后续定位排查提供必要的依据。


发现问题关键

org.apache.ibatis.executor.result.Defau

ltResultHandler 内部持有一个 List，其原始为 java.util.HashMap，从这个类基本可以看出是与数据库的查询相关，对数据库返回结果的解码并组织成 HashMap。这个 List 中的元素总共有 146033 个，初步可以判断出是在一次查询中从数据库中一次查询出了太多数据，造成了内存溢出。

由于 SQL 查询代码中，是用 HashMap 来接收数据库中的返回字段，无法一时间看出是那个查询，那我们能不能精确找到是哪一个查询，哪一行代码，甚至与哪一条 SQL 语句呢？

视图使用技巧：展开技巧：沿着使用率最高的项一层一层进行展开，直至发现具体占用内存的对象。接下来我们从 视图去寻找是哪个方法，哪条 SQL 语句触发的。

继续往上查找，要找到 SQL 语句，应该找到 Mybatis 处理结果集相关的类。

---

总结

日志是分析问题的经典策略，灵活地使用日志能够分析问题。