小心递归中内存泄漏

前段时间由于业务需要,需要从数据库中查询出来所有满足条件的数据,然后导入到文件中。于是随便写了个程序,查询出所有满足条件然后再写入文件。但是实际上线后却发现,程序刚开始运行马上看到部分数据写入到文件,但是后面运行越来越慢,于是对此分析排查了一下。

应用环境

JDK 1.7 + Spring 4.3 + mybatis + oracle

问题排查

查询以及写入文件伪代码如下:

其中 为一个分页查找方法。这个方法目的就在于递归查找分页数据,如果某一页数据为空,就代表查询结束,此时已查询出所有数据。

为什么不直接执行 类似的数据直接查出所有数据?

因为写程序之前,查询了一下满足条件的数据总共有 200 w 数据,这样如果直接一把查询出所有数据,主要担心堆内存直接占满,导致OOM错误。

写完代码,部署到线上,然后执行导出数据,就放着不管,干其他事。过一段时间回来看数据导出结果,这个时候大吃一惊,程序竟然还没有结束,数据也才导出 3/4 左右。这个时候意识到程序肯定存在问题,于是仔细检查了一遍代码,也没看出什么。

没办法,这个时候只能分析线上程序 GC 情况了,幸好开启了打印 GC 日志的选项。拿到 GC 日志文件后,由于不太精通 GC 日志详细内容,只能借靠外部力量了。GC 日志分析网站,该网站可以分析 GC 日志,然后可以查看各个时间点堆内存占用情况。分析情况如图。

这张图为 GC 之后堆内存占用情况。可以看出堆内存在 Full GC 之后并没有很快的降下来且很快下一次 Full GC 就开始了。这样大致可以看出,程序没有在期待时间内运行结束,就是由于堆内被占用过多,持续引起Full GC,应用程序线程持续被挂起。然后我们再看堆内存老年代占用情况。

如上图,堆内存老年代占用空间持续上升直到接近占满,引起 Full GC,并没有缓解这种情况,之后内存占用一直接近到占满。

综上,我们可以得知程序出现了内存泄漏。

知道了原因,我们就好顺着找到问题。又顺着捋了一遍代码,可惜的是并没有看出问题。难道是allData数据集合越来越大,然后导致该现象?仔细查看了 代码逻辑。

可以看到,数据一旦写入到文件中,allData集合立刻清空,所以不可能是该问题导致。

看了好几遍代码之后,还是无法确定问题原因。最后一遍查看代码,灵关一现,不会是newQueryData导致的问题吧?尝试把这里代码改成下面方式。

改完代码,立刻部署,开始运行程序。这个时候查看堆内存占用情况,就可以知道改动是否有效。这里推荐一个方便查看 JVM 进程信息的工具 vjtop。可以快速查看堆内存占用情况。

运行 vjtop 之后,一直盯着堆内存占用情况。然后发现 eden 空间持续上升直到接近到满,然后发生 Minor GC ,eden 空间迅速清空。 old 区内存也没有一直占用接近到满这么夸张。大概占用 1/5 内存。改善情况如想象中一致,等待一定时间后,数据导出完毕。

分析

现在我们分析为什么出现内存泄漏。

我们知道 jvm 运行时,内存区分为 堆,虚拟机栈,方法区等。上面我们发生的现象就与虚拟机栈有关。

什么事虚拟机栈?

摘录深入 Java 虚拟机一书解释

虚拟机栈描述的是 Java 方法执行的内存模型:每个方法执行时都会创建一个栈帧用于存储局部变量表,操作数栈,动态链接,方法出口等信息。每一个方法从调用直至执行完后的过程,就对应一个栈帧在虚拟机栈中入栈到出栈的过程。

Java 线程执行方法时,jvm 虚拟机栈数据结构如图所示。

可以看出,我们在调用函数 1 时,就将该栈帧压如栈中。函数 1 调用函数 2 时,也将该栈帧压入栈中。处于栈中的栈帧包含局部变量表,操作数帧等,而局部变量表包含基本数据类型,以及对象引用指针。对象指针指向堆内存对象。就是因为对象引用指针,导致我们上面情况。为何这么说那。我们再看下面这张图。

我们可以看到,栈中每个方法 newQueryData 都指向堆中真正的对象。由于递归执行时,前面的方法都压到栈中,newQueryData 一直还指向堆中对象,然后 GC 时,由于对象还处于被引用,虚拟机判定该对象存活,所以不清理这些对象。随着递归方法越来越深入,堆积的 newQueryData 越来越多,量表引起质变,导致堆内存被占满,引发虚拟机持续 GC。但是每次 GC 之后却无法腾出空间。最后我们看到的现象就是程序执行很慢很慢。

 总结

这个问题本质看起来不是很难,但是实际发生的时候排查问题着实花费不少时间。下面我们总结一下这个过程。

如果程序实际运行起来与预想差距太大,那么不用想了,肯定哪里出问题了,赶快登上机器查看吧。

程序运行必要节点的日志输出需要打印。上面程序本来刚开始写的时候,由于主观意思,想想没那么难,很快就撸完部署了。最后查看日志,由于没有必要的日志输出,都不知道程序卡在那了。

需要了解一些 JVM 相关工具,可以及时查看 JVM 相关情况,如内存使用情况。如本文的例子,实际上我们可以 dump 内存,然后分析哪里发生了内存泄漏。很不幸的是,这方面本人只是处于了解层面,用的时候却不知道如何下手,只好求助于一些现成开源工具完成。之后需要好好补这方面操作能力,哈哈哈。

本文如果使用 while 循环代替递归方式,问题可能更快定位。递归中的内存泄漏可能更加隐蔽,很容易被我们忽略,同学们下次再写递归方法的时候不仅要注意递归方法深度,还要注意这个过程需要及时释放无用对象,不要让内存泄漏发生。

好了,文章大概就这样了,下次文章再见了。

参考文章以及网站

深入 Java 虚拟机 堆内存章节

Java JVM 中 堆,栈,方法区 详解

gc 日志分析网站

查看 JVM 进程信息的工具 -- vjtop

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181212G1G5CT00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券