mybatis粗心使用导致内存溢出

阿星不是程序员

已于 2023-04-25 10:11:03 修改

阅读量1.8k

点赞数

分类专栏： mybatis 文章标签： mybatis

于 2023-04-24 15:39:26 首次发布

本文链接：https://blog.csdn.net/guntun8987/article/details/130341626

版权

mybatis 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

文章描述了一个基础业务服务因内存溢出导致响应变慢的问题。通过分析GC日志和线程堆转储文件，发现是由于一次查询大量数据（几十万条）且由于方法重用，未传入的departmentIdList参数导致。解决方案是创建新的方法并增加条件限制，避免在departmentIdList为null时查询全部数据。

摘要由CSDN通过智能技术生成

现象

服务响应变慢，线程日志也出现Java heap space内存溢出的错误，这个服务属于基础业务服务，出现问题要尽快的排查

分析

因为设置了gc日志和jmap启动相关参数

所以我们进行分析，这里模拟线上环境将堆大小参数调整到了128m，完成的参数

-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms64M -Xmx64M -Xloggc:./gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+HeapDumpOnOutOfMemoryError

下面来分析这两个文件

gc.log

在这里插入图片描述

可以很明显的看出gc已经不能把对象进行回收了发生了内存泄露

hprof文件

在这里插入图片描述
从这张图能看到tomcat的一个线程里面的逻辑是从mysql查询数据，其中有个数据库字段类型为text占用空间比较大，映射的对象由于是String类型所以显示的是byte[]数组占用为2000byte。这个数组在这个集合内还有很多很多…

这肯定是不正常的现象，然后我们从日志调用链路查到了具体的接口，看到了mybatis中这条sql的逻辑
在这里插入图片描述
问题在departmentIdList参数，通过日志我们看到这个参数其实是没有传进来的为null，所以if条件是不进入的，这就导致把没必要的数据也全都查了出来，一次性查出了几十万的数据，再由于qps比较高，一下子就内存溢出了。