导出excel 大数据量分页_解决大批量Excel导出OOM问题

1、背景介绍：最近一直被OOM问题缠绕，原因是表单下载功能访问量比较大，数据量相当多，表单数据存储在mongodb，数据总量2亿多，每个实例总内存限制1.5G左右，线上部署了5个实例，但是最大承受时间也不过3天，于是决定逐步优化解决此问题

2、环境介绍：

2.1、vm: openjdk:8-jre-alpine

2.2、docker 部署，k8s管理

3、问题呈现：

3.1、导出大批量Excel时，nginx 504

3.2、访问量高 && 导出大批量Excel，出现OOM

4、问题分析：

4.1、nginx 504 问题，服务器长时间无响应，根本原因是同步操作，mongodb查询慢

4.2、数据保存在mongodb，mongodb分页是深分页，会全表扫描

5、解决办法：

5.1、导出采用异步操作，多线程异步处理

5.2、大批量的Excel采用下载到磁盘，统一压缩为zip文件上传到腾讯云，

5.3、能尽量用基本类型的不使用引用类型异步操作如图示

具体代码如下：

设置线程池，核心线程数不是越大越好，具体文章请参考

https://blog.csdn.net/wang123459/article/details/82079250

线程池资料参考

https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/scheduling/concurrent/ThreadPoolTaskExecutor.html

代码逻辑具体实现：

优化完之后，遗憾的是只能在线上坚挺了不到2天，某一个实例又爆出OOM了，由于添加了jvm监控，异常监控截图如下：

经过分析是由于Eden space 无法为新生对象开辟新的空间，发生了OOM，java堆内存划分如下:

从以下几点分析：(1)内存中加载的数据量过于庞大，如一次从数据库取出过多数据；

(2)集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

(3)代码中存在死循环或循环产生过多重复的对象实体；

(4)使用的第三方软件中的BUG；

(5)启动参数内存值设定的过小；

受到启发：1、 代码中尽量少使用引用类型2、增大java堆内存3、设置合理的垃圾回收器

验证结果：

1、模拟大批量数据导出：并发请求10-20次，每个请求的数据导出下载量是30w条左右，结果如下：

30w条数据异步导出执行大概需要2-3秒就可以完成，

JVM堆运行情况如下：

其实在极限的条件下，选用合适的方法，而不是现在的服务器配置都很高，而不注重性能相关的问题，程序员的经验不能以工作年限而一味的判定，而是凭处理问题的思路和应变能力，

个人理解牛逼的高手都是在发现问题，解决问题的过程中历练出来的，而不是无谓的代码堆积，那就真正把自己变成的搬砖的了