ef+Npoi导出百万行excel之踩坑记

Posted qqljcn

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ef+Npoi导出百万行excel之踩坑记相关的知识,希望对你有一定的参考价值。

        最近在做一个需求是导出较大的excel,本文是记录我在做需求过程中遇到的几个问题和解题方法,给大家分享一下,一来可以帮助同样遇到问题的朋友,二呢,各位大神也许有更好的方法可以指点小弟一下,让我顺便学习一下。
背景::工头:“小钟啊,xx界面加个导出excel功能03以后的格式,需要能支持到excel的最大行,同时需要5个并发就行”
我:“收到,但是数据大的时候速度可能比较慢。”
工头:“你先做后续客户反馈了在给他加进度条。”
Npoi神器介绍:SXSSFWorkbook 专门用来导出大数据用,他会把数据先写入C盘的临时目录;不会所有 都留在内存里;更详细介绍请百度或者参考(http://poi.apache.org/components/spreadsheet/how-to.html#sxssf
有了这层基础开始劈里啪啦一段操作写代码;(以下代码非生产代码只是我为了帖子写重现问题的测试代码)
首先开个线程模拟并发
技术图片
编写导出方法:记录时间、创建SXSSFWorkbook 代码如图:
技术图片
启动运行;
技术图片
好!第一口锅已造好,看这个提示,前面说了SXSSFWorkbook 是会先把缓存数据写入Windows临时文件里头的,这个目录正好是Windows的临时文件夹虽然是个错误但是验证了刚刚的说法;至于这个错误看提示 我们有个大胆的想法是文件占用问题,应该是创建文件的时候文件已经存在了,这样我们把npoi的dll打开来看看,通过看源码和各种f12我们看到了这么一段代码
技术图片
这里看到用来随机数,而我们知道net的随机数在极短的时间内生成是不可靠的(详见百度或者:
技术图片
 
早在年初NPOI就对这个问题做了更改就换成guid了,随后我来到了nuget
技术图片
nuget最新版 是去年12月份发布,并没有包含上面的更改;
所以呢 要么github下载最新版编译要么自己解决,想了想如果换版本的话以前的功能可能会影响到所以,我们就在外面加一把小锁吧!如图
技术图片
 
技术图片
这样呢我们在试试!
技术图片
 
很好 不会在出现文件占用问题了;好继续导出!
既然是都先写入缓存文件是不是占用的内存就很小了 来看看
技术图片
2G多。。。什么情况,还在涨
技术图片
 
3G。。。这明显不符合工头的需求了,然后终于它炸了
技术图片
第一念头是为啥我该怎么办,设置GC的回收模式?手动多GC?还是要把代码给拿下来看看,看看这么大内存哪里没释放文件?冷静、冷静、想想,既然是内存爆了 那么正确流程应该是抓取看看是什么吃的内存得出结果再去改东西,
技术图片
发现了啥是不是很熟悉的东西? 状态管理、包装类,想到了啥 EF的“模型跟踪”这个功能占用的内存最大了。那就去掉吧 加上这么一句 意思是无跟踪查询 ,修改实例后SaveChanges不对对它生效;
技术图片
(AsNoTracking 更详情理解介绍请百度在加上msdn:https://docs.microsoft.com/zh-cn/ef/ef6/querying/no-tracking?redirectedfrom=MSDN
现在在继续导出看看:
技术图片
内存是吃的不大了,
技术图片
可以看出临时文件还是很大的,这还没导完呢,所以做的时候 尽量要保证下硬盘的空间!
等待。。。
总结:
1.导出大数据用SXSSFWorkbook
2.构建SXSSFWorkbook 时候lock或者自己编译最新版本
3.我们做导出时,ef查询数据后记得加AsNoTracking 关闭绑定跟踪。(以后日常开发中如果只需要查询的也可以这样做)
4.SXSSFWorkbook 导出大数据 临时文件夹所在的硬盘不能太小 因为会生成大于excel本身的缓存文件!
技术图片
 
技术图片
 
技术图片
最后导出完毕
技术图片
用时:
技术图片
 
技术图片

以上是关于ef+Npoi导出百万行excel之踩坑记的主要内容,如果未能解决你的问题,请参考以下文章

Azure 跨订阅迁移资源踩坑记

Spring @Transactional踩坑记

HttpWebRequest 改为 HttpClient 踩坑记-请求头设置

FastDFS踩坑记

iptables踩坑记

windows container 踩坑记