定位jvm内存溢出

￡神魔★判官ぃ 2022-02-22 16:56 251阅读 0赞

## 生产环境JVM内存溢出案例分析 ##

中间件兴趣圈 **中间件兴趣圈**

微信号dingwpmz\_zjj

功能介绍关注后端技术架构、java多线程、并发、Netty、Mycat、Dubbo、ElasticJob、RocketMQ、Elasticsearch等中间件技术。

*前天*

如果我们所在公司的业务量比较大，在生产环境经常会出现JVM内存溢出的现象，那我们该如何快速响应，快速定位，快速恢复问题呢？

本文将通过一个线上环境JVM内存溢出的案例向大家介绍一下处理思路与分析方法。

案例：架构组接到某项目组反馈，Zabbix监控上显示JMX不可用，请求协助处理。

分析思路：

*  JMX不可用，往往是由于垃圾回收时间停顿时间过长、内存溢出等问题引起的。
 *  线上故障分析的原则是首先要采取措施快速恢复故障对业务的影响，然后才是采集信息、分析定位问题，并最终给出解决办法。

具体分析过程如下。

### 如何快速恢复业务 ###

通常线上的故障会对业务造成重大影响，影响用户体验，故如果线上服务器出现故障，应规避对业务造成影响，但不能简单的重启服务器，因为需要尽可能保留现场，为后续的问题分析打下基础。

那我们如何快速规避对业务的影响，并能保留现场呢？

通常的做法是隔离故障服务器。

通常线上服务器是集群部署，一个好的分布式负载方案会自动剔除故障的机器，从而实现高可用架构，但如果未被剔除，则需要运维人员将故障服务器进行剔除，保留现场进行分析。

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

### 分析解决问题 ###

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

![20190409180255688.png][]

收集内存溢出Dump文件

收集Dump文件有两种方式：

*  设置JVM启动参数  
    \-XX:+HeapDumpOnOutOfMemoryError  
    \-XX:HeapDumpPath=/opt/jvmdump

在每次发生内存溢出时，JVM会自动将堆转储，dump文件存放在-XX:HeapDumpPath指定的路径下。

*  使用jmap命令收集  
    通过jmap -dump:live,format=b,file=/opt/jvm/dump.hprof pid。

分析Dump文件

在获取Dump文件后，可以使用工具MAT(MemoryAnalyzer)进行分析，该工具大家可以通过百度自行下载。

使用MAT打开Dump文件后，首页截图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70][]

工具按钮介绍：

直方图视图，将堆中所有的内存消耗情况统计出来，其如图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 1][]

根据该图，可以明确，堆的总大小为1.9G，被4个线程全部占据，导致其他线程无法再申请资源，抛出堆内存溢出错误。

接下来，我通常的做法是直接去看这个视图(以线程为基本维度，查找线程中占用内存的对象)，为后续定位排查提供必要的依据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 2][]

从上面的截图中可以得出如下关键信息点：

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

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

答案是可以的，我们可以从图一探究竟。

> 温馨提示：  
> 视图使用技巧：展开技巧：沿着使用率最高的项一层一层进行展开，直至发现具体占用内存的对象。

接下来我们从 视图去寻找是哪个方法，哪条SQL语句触发的。

具体方法：首先完全展开一个线程，从展开图的底部向上寻找：  
其线程的入口(控制层代码)

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 3][]

然后鼠标可以放在SQL属性中，右键，可以将SQL语句复制出来。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 4][]

由于这里涉及到公司的代码机密，故在这里不贴出具体的SQL语句。

这里根据后面的分析，原来是在做导出功能的时候，没有使用分页对数据进行分页查询，分页写入Excel文件，而是一次将全部数据查询，导致导出功能如果并发数超过4个时，就会将所有内存耗尽。

解决方案：

*  首先在运维层面将该请求导入到指定的一台服务器上，是导出任务与其他任务进行隔离，避免对其他重要服务造成影响。
 *  项目组对其代码进行修复，可以使用分页查数据，然后分配写入Excel。

> 作者简介：丁威，RocketMQ早期布道者、《RocketMQ技术内幕》作者、中间件兴趣圈公众号维护者。

[20190409180255688.png]: /images/20220222/0e7c1befc679484d8486d86344965168.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70]: /images/20220222/d2e113aaf9ec4679bc6083fcef84a12e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 1]: /images/20220222/6d9911b92d144f1d925fd7b94cb825c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 2]: /images/20220222/c7f3c10fefe14178bd81d20989e6e8a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 3]: /images/20220222/a9f6dc3c6118451094f3ca9330d6d2db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 4]: /images/20220222/a852f115677e48b0b25130531df6314e.png