记一次内存溢出处理经历

2021/11/29 7:06:13

本文主要是介绍记一次内存溢出处理经历,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

最近刚上线一个项目,没过多久测试反馈说导出excel的功能很卡,卡着卡着网站就崩了。

用jstat查了一下,发现导出大量数据的时候,老年代的占比一直在升高,没有降低过,而且cpu一直在狂转,感觉是在不停gc,但是又没有释放多少空间。用jmap查看了一下,发现占用内存最多的是apache命名空间下的类(查了一下好像是poi相关的类)和导数据相关的实体。分析了一下线上数据,发现这个报表的功能所涉及的数据量非常大,一共10来个sheet页,每个sheet页几十万到上百万的数据量。
看了一下源代码,由于相关数据是来源于多个数据源,通过接口返回,在内存中做的计算。所以就制定了一个初步的修改方案:
1、由于之前处理整个导出是放在一个大方法中的,大的方法里面会调用各个接口取到数据然后填充数据到各个sheet的。这样存在一个问题,各个接口返回的数据要等到整个方法结束才能被垃圾回收释放掉。所以需要把各个sheet页的处理单独拆成多个子方法,这样每个sheet的填充后相关数据就可以及时释放。
2、之前代码中没有考虑数据量,很多地方使用list做查找的,小的数据量下这样没有问题,针对多个几十万、上百万的集合这样做效率就太低了,所以相关集合改为 map。
3、优化取数据的接口,只返回所需字段,减少传输量。
4、针对一次返回太多数据的接口,可以优化成两步,先只返回id列,然后把返回的id按照一定大小分页查询,这样可以避免接口服务器一次处理太多数据卡顿。
5、很多地方都在重复查询相同的数据,可以通过定义RequestScope的缓存对象解决。
6、有很多地方为了重用计算逻辑,存在深克隆对象的情况,可以简单重构一下,计算的地方依赖接口,实体只需要实现接口,就不需要转换实体对象也能保证计算逻辑可重用。
7、上面提到的大量poi相关的类,经过反复测试,发现是单元格上面添加的样式导致的,经过同用户沟通,不使用样式用户也是可以接受的,只是需要输出的时候转换一下日期、金额等格式。
经过以上修改,导出功能总算正常了,内存也一直很平稳,时间也降下来了。



这篇关于记一次内存溢出处理经历的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程