Java POI XSSF是否仍然存在严重的内存问题？

几年前，我遇到了使用

jXLS

和

POI-XSSF

创建大型excel文件的问题。如果我的内存是正确的，我想

XSSF

会在磁盘上创建类似1GB+temp的文件来创建10mb的excel文件。因此，我停止使用

jXLS

，而是使用

SXSSF

创建excel文件，但今天我有了使用

jXLS

或

JETT

的新理由

jXLS

和

JETT

网站似乎都暗示性能更好，但

POI

的

XSSF

网站仍然笼统地说

XSSF

需要更高的内存占用。我想知道，这更高的内存占用率是不是相当于目前10%的开销，还是仍然像几年前一样是10000%的开销

---

POI 3.9

XSSF

是否修复了疯狂的坏内存问题？我应该不担心与

jXLS

或

JETT

一起使用它吗？还是有某些陷阱需要避免？我很小心重复使用单元格样式。

回答您的问题，是的，POI在处理大型XLSX文件时总是使用非常大的内存，这比XLSX文件的大小大得多。 我认为这不会很快改变，原因很明显：XLSX基本上是一堆压缩的XML文件，XML压缩得很好（大约10倍）。如果将此XML放在内存中解压，则内存消耗将增加十倍，因此，如果将数据结构的所有开销都加在一起，就不可能比XLSX文件大小增加10%的内存消耗

好消息是，正如评论中提到的，ApachePOI在电子表格中引入了大量数据流，具有非常好的性能和较低的内存使用率。以这种方式生成的XLSX文件仍然在硬盘上传输，最终可能会占用相当大的空间，但至少在写入数十万行时不会冒OOME的风险

您的问题是无法让JETT直接使用SXSSF，因为它需要在内存中加载整个文档来执行模板填充。JETT的作者很快讨论了这个话题

我也遇到了同样的问题，最终完成了两步XLSX创建：

用于生成标题和格式的标准JETT XLSX模板。第一张工作表的最后一行包含带有$$tokens$$的单元格，每个单元格一个。我不使用JETT插入大量行

JETT完成工作后，我重新打开工作簿，读取并删除第一个电子表格最后一行的$$tokens$$，然后开始使用SXSSF逐行传输数据

当然，这种方法也有局限性： -在行插入期间，您不能在任何流式行上使用JETT（但您可以在此之前动态选择$$tokens$$的顺序，例如） -除非您使用POI API自行处理，否则不会复制单元格格式。我个人更喜欢格式化XLSX文件中的整列，它将应用于流数据

---

如果要使用随SXSSF插入的数据显示图表，也可以这样做：可以使用函数OFFSET和COUNTA定义命名范围，然后创建透视表和透视图，在Excel中打开XLSX时将刷新该透视表和透视图

这个问题感觉很模糊，但请自己看看发布的内容：。看起来它没有明确的地址。无论您做什么，使用

.xlsx

将需要比

.xls

更多的内存或临时文件，因为所有XML和压缩的开销都高于二进制文件formats@James当前位置我不知道怎样才能不那么含糊。大约10%的管理费用似乎合理，10000%的管理费用则不合理。我试图找出内存开销是否仍像以前一样在10000%左右，或者是否接近10%。@Gagravarr:.xls无法处理大型excel文件（限制为65536行），因此它不是一个选项。另外，使用XSSFX的内存占用开销小于HSSF，因此.xlsx需要的内存或临时文件不一定比.xls多。@James：对不起，我的意思是我已经浏览了那个更改文档（以及其他许多地方）。我没有发现任何明确的证据表明内存问题已经解决，但有可能是一个逻辑错误导致了这个问题，而这个问题没有列在xml或内存中。也有可能是jxls中有一个bug导致了这种情况（尽管我从其他人那里听说，他们因为与jxls无关的内存问题而拒绝使用XSSF）。我希望其他人知道这个内存问题是否已经消失，这样我就不用花很多时间测试了。我不同意POI必须使用大量内存和/或大量临时文件。按照你的回答逻辑，Excel、OpenOffice和LibreOffice都会遇到同样的内存问题。我认为真正的问题是POI使用了糟糕的内部数据结构设计——我认为一般来说，xml文件比zip文件大12倍。在生成报告的过程中，POI使用的临时文件比生成的xlsx文件大1000倍——因此，造成问题的肯定不仅仅是压缩。我明白您的观点，Excel/Office/LibreOffice能够毫无问题地加载巨大的xlsx文件，但我相信这些软件必须使用优化的内部结构，才能有效地存储应用程序中显示的数据。另一方面，POI是一个库，它从XLS格式的接口开始，并保留相同的接口以允许修改基于XML的XLSX格式。保留XML结构的等价物以进行更改是有意义的，因为写回XLSX格式非常简单，而不是经过优化的数据结构。