为什么Apache POI处理xlsx文件时内存与存储占用过高？

要搞懂这个问题，首先得明确XLSX文件的本质：它本质是一个ZIP格式的压缩包，把后缀改为.zip解压后，内部是一堆按规范组织的XML文件——每个工作表对应一个独立的sheet XML，另外还有存放共享字符串、单元格样式、公式、批注的配套XML文件。POI的资源消耗高，完全是和它的解析/写入逻辑、XLSX本身的格式特性绑定的：

读取时XSSFWorkbook触发OOM的核心原因 #

• XSSFWorkbook采用的是全量对象驻留模型：读取时会先把XLSX压缩包完全解压，再把所有XML节点全部解析成带层级的Java对象，全部堆在JVM堆内存里。它存的不只是单元格的显示值，连单元格样式、字体、批注、公式、合并规则、数据校验规则这些关联属性都会生成对应的Java对象。
• 内存膨胀比远高于文件本身大小：常规业务数据生成的XLSX，内部XML的压缩率通常在10:1到20:1区间，你手里90MB的XLSX解压后原始XML体积大概率已经在1GB上下；再加上Java对象本身的对象头、引用指针、集合类的额外开销，对象树的实际内存占用会比原始XML再膨胀3~5倍，哪怕给JVM分配几GB堆内存也很容易触发OOM。
• 你改用XSSF+SAX事件驱动模式能避免OOM，本质是它不会构建全量对象树，只会顺着XML流顺序扫描，扫到对应节点就触发事件回调，你只需要提取当前需要的字段值即可，用完的节点内存直接回收，内存占用可以稳定在几十MB级别，但代价是只能顺序读，无法随机访问、修改任意位置的单元格。

SXSSF写入时临时文件体积极大的核心原因 #

SXSSF是POI为大文件写入设计的低内存API，原理是只在内存里保留指定行数的最新行（默认100行），超过阈值的行会被提前序列化写入临时文件，等最后收尾的时候再把临时文件内容拼起来，压缩打包成最终的XLSX文件。临时文件体积膨胀严重主要是两个原因：

• 临时文件存的是无压缩的纯XML明文，没有做任何ZIP压缩。XML本身的标签冗余度极高：比如CSV里一个存12345的数字单元格，只占5个字符；转成XML后要套上<row><c r="A1"><v>12345</v></c></row>一整套标签，仅标签部分的字符量就是单元格值的好几倍，文本类单元格还要额外处理转义字符，冗余度更高。
• 最终生成XLSX时会把这些XML片段做高压缩比的ZIP打包，反过来算的话，1GB的未压缩XML压缩后可能只有几十MB，和官方文档提到的"20MB CSV生成1GB临时文件"的膨胀比例是完全匹配的。

如果觉得临时文件太占磁盘，可以在创建SXSSFWorkbook时调用setCompressTempFiles(true)开启临时文件的GZIP压缩，通常能把临时文件体积压到原来的1/10左右，只会增加少量CPU开销。另外注意这些临时文件默认会在JVM正常退出时自动删除，如果进程异常崩溃可能残留，需要自己定时清理临时目录。

内容的提问来源于stack exchange，提问作者Master Qiao