线上报了内存溢出异常，又不完全是内存溢出

2022-04-28 337

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

日志服务 SLS，月写入数据量 50GB 1个月

简介： 最近一直忙于对付即将上线的系统，期间也碰到了很多问题。最近印象比较深的是一个内存溢出的报错。测试告诉我最近某个功能总是没有效果，于是我就去线上看了一下错误日志，这不看不知道，一看吓一跳，满屏的OutOfMemoryError ，出于隐私保护，这里只展示其中的一点异常信息：

听说微信搜索《Java鱼仔》会变更强哦！

本文收录于github和gitee ，里面有我完整的Java系列文章，学习或面试都可以看看哦

（一）前言

最近一直忙于对付即将上线的系统，期间也碰到了很多问题。最近印象比较深的是一个内存溢出的报错。测试告诉我最近某个功能总是没有效果，于是我就去线上看了一下错误日志，这不看不知道，一看吓一跳，满屏的OutOfMemoryError ，出于隐私保护，这里只展示其中的一点异常信息：

网络异常，图片无法展示

（二）思考场景

一般查问题首先是看日志，然后是思考场景，为什么在这个场景下会发生内存溢出的异常。于是我就思考了一下这段代码的逻辑，这里是一个异步线程的数据提取功能：通过dubbo接口，每次调用1000条数据，再对这些数据做一些处理后落入库，数据的总量在几万至几十万不等。

这里如果会出现内存溢出，唯一有可能的是每次调用的1000条数据在数据处理后没有清空，导致几十万数据都加入进内存中，最后内存溢出。于是去检查了这部分的代码：

List<EmrTreatment>resultList=newArrayList<>();
//如果数据还有，则不跳出循环while (CollectionUtils.isNotEmpty(data.getRecords())) {
resultList.addAll(dataPage.getRecords());
//业务处理//.......//清空集合防止内存溢出resultList.clear();
// 通过dubbo接口请求接下来的1000条//... ...data=searchDataByScroll(dataRequest);  
}

我特意在1000条处理完成后清空了List，就不存在内存溢出的情况。

（三）查看GC日志

因为是堆内存溢出，于是立刻想到了去看看GC日志，但是一点内存溢出的意思也没有，顺便重温一下GC日志的内容表示的含义：

网络异常，图片无法展示

以其中的单条为例：

GC (AllocationFailure) 2021-10-29T16:37:45.177+0900: 2686.339  [ParNew: 283195K->3579K(314560K), 0.0256691secs] 396015K->116915K(1013632K), 0.0258253secs] [Times: user=0.03sys=0.02, real=0.03secs]

GC：表明进行了一次垃圾回收，属于MinorGC

Allocation Failure：GC发生原因是因为年轻代空间不足

ParNew：本次GC年轻代使用的是ParNew垃圾收集器

283195K->3579K(314560K)：GC前年轻代使用量->GC后年轻代使用量(年轻代总容量)

396015K->116915K(1013632K)：堆区垃圾回收前使用量->堆区垃圾回收后使用量(堆大小)

[Times: user=0.04 sys=0.00, real=0.01 secs]：

user：垃圾收集线程消耗的所有CPU时间

sys：系统等待时间

real：应用暂停总时间（STW）

既然GC日志中没有堆内存溢出的信息，说明不是我们应用的内存溢出，又仔细看了一下报错信息，有很明显的错误指向dubbo，说明之前的路走歪了。

（四）检查dubbo接口配置

依稀记得dubbo接口调用时设置了每次的调用大小，于是上nacos检查配置，果然dubbo接口设置了16M的大小，这一下就定位到问题了。每次从dubbo接口取1000条数据在某些数据量比较大的情况下超过了16M，返回了一个OutOfMemory Error。

（五）解决方案

既然定位到了问题，解决方案也就简单了，首先根据实际情况调整dubbo接口的消费者和生产者限制大小，其次将每次调用1000次修改略微小一点。再者按照原来的设计1000条数据是不会超过16M的，于是检查了数据，发现有的数据单条就超过了2M，这类数据的使用价值不大，因此在产品上考虑是否过滤掉这些数据。最终上线验证没有再报同样的问题，算是解决了。

（六）总结

虽然问题是解决了，但是还是走了一些歪路。碰到紧急问题时脑子不会像事后那么清晰，但是踩的坑越多，学到的也就越多。