多人同时导出 Excel 导致内存溢出

1、问题根因分析

多人同时导出Excel导致内存溢出（OOM）的核心原因是：在短时间内，大量数据被加载到JVM堆内存中，且创建了大量大对象（如Apache POI的Cell、Row、Sheet对象），超过了堆内存的最大限制（-Xmx）。

同步处理与高并发：导出请求通常是同步的。当多个用户同时触发导出时，每个请求都会在服务器端创建一个处理线程，并在该线程中构建一个完整的、包含大量数据的Excel工作簿（Workbook）对象。
Apache POI的内存模型：传统的Apache POI（如HSSF/XSSF）在构建Excel时，所有单元格、样式、数据都保存在内存中的Java对象里。一个几十万行的Excel文件，其对应的Workbook对象可能轻松占用几百MB甚至上GB的内存。
数据一次性加载 ：为了生成Excel，通常需要从数据库一次性查询出所有数据，这个巨大的ResultSet也会占用大量内存。
JVM堆空间不足 ：如果JVM堆内存设置本身不大，或者并发导出的用户数足够多，就很容易将堆内存耗尽，触发java.lang.OutOfMemoryError: Java heap space。

2、解决方案（从低代价到高代价，从临时到根本）

2.1 应用层优化（代码改造 - 最根本的解决方案）

这是最推荐的方式，从根源上解决内存问题。

a) 使用流式API (SXSSF)

Apache POI提供了专门用于处理大数据量的流式API：SXSSF。

原理

SXSSF（Streaming Usermodel API）在XSSF的基础上扩展，它只会将一部分行（例如100行）保留在内存中，生成一行，刷新一行到磁盘临时文件，从而实现低内存占用。它通过滑动窗口机制来管理内存中的行。

优点：内存占用极低且恒定（仅与rowAccessWindowSize有关），是解决此问题的最佳武器。
缺点：不支持一些高级特性（如公式计算、单元格合并等在刷新后可能受限），会生成临时文件。

代码示例

复制代码

// 设置一个滑动窗口值，表示在内存中保留多少行，超出的行会被写入磁盘
int rowAccessWindowSize = 100;
SXSSFWorkbook workbook = new SXSSFWorkbook(rowAccessWindowSize);
SXSSFSheet sheet = workbook.createSheet("数据导出");

// 写入表头
Row headerRow = sheet.createRow(0);
headerRow.createCell(0).setCellValue("姓名");
headerRow.createCell(1).setCellValue("年龄");

// 流式分页查询数据库并写入
int pageSize = 1000;
int pageNum = 1;
List<Data> dataList;
int currentRow = 1;

do {
    // 1. 分页查询，避免一次性加载所有数据
    dataList = dataService.getExportData(pageNum, pageSize);
    if (dataList.isEmpty()) {
        break;
    }

    // 2. 将本页数据写入Excel
    for (Data data : dataList) {
        Row row = sheet.createRow(currentRow++);
        row.createCell(0).setCellValue(data.getName());
        row.createCell(1).setCellValue(data.getAge());
        // ... 其他单元格
    }

    // 3. 非常重要！手动清理掉滑动窗口之外的行，释放内存
    // ((SXSSFSheet)sheet).flushRows() 也可以，但注意参数
    ((SXSSFSheet) sheet).flushRows(dataList.size()); // 刷新并清理已处理的行

    pageNum++;
} while (!dataList.isEmpty());

// 将workbook写入HttpServletResponse的输出流
workbook.write(response.getOutputStream());
workbook.dispose(); // 删除临时文件
workbook.close();

b) 分页查询数据库

如上例所示，在数据获取层，绝对不要一次性SELECT * FROM huge_table，必须使用分页查询（如MySQL的LIMIT offset, size）。这大大降低了数据库和Java应用两边的内存压力。

2.2 架构与流程优化

a) 异步导出

将同步请求改为异步任务。

流程：
- 用户点击导出后，服务端立即返回一个任务ID或一个URL："正在生成，请稍后查看下载链接"。
- 后台使用一个独立的、线程池大小可控的任务（如使用@Async、消息队列、Job调度）来执行真正的导出操作。
- 导出完成后，将文件上传到OSS或文件服务器，并将下载链接通过通知系统（站内信、邮件等）告知用户，或者更新任务状态供用户查询。
优点：
- 避免了HTTP请求超时。
- 可以对后台任务队列进行控流，避免同时处理过多导出任务，从而控制内存使用峰值。
- 用户体验更好，不会因为长时间等待而导致浏览器卡死。
缺点：系统设计更复杂，不能立即下载。

b) 限流与队列

如果必须同步导出，可以在应用入口进行限流。

使用RateLimiter（Guava）或Sentinel等工具，限制单位时间内允许的导出请求数量。例如，最多只允许同时处理2个导出请求，后续请求排队等待或直接返回"系统繁忙，请稍后再试"。
优点：简单粗暴，有效防止系统被瞬时高并发打垮。
缺点：用户体验差（需要等待或失败）。

2.3 运维与配置优化（临时缓解措施）

这些不能根治问题，但可以作为一个缓冲或辅助手段。

a) 增加JVM堆内存

通过调整启动参数 -Xmx4g -Xms4g 来增大最大堆内存。

优点：简单，快速。
缺点：
- 只是推迟了OOM发生的时间，如果数据量或并发量持续增长，迟早还会溢出。
- 大内存会带来更长时间的Full GC（Garbage Collection），导致应用"卡顿"。

b) 优化GC参数

针对大内存和创建大量短命对象（导出任务中的对象基本都是短命对象）的场景，使用G1垃圾收集器可能效果更好。

参数示例：-XX:+UseG1GC -XX:MaxGCPauseMillis=200

c) 文件拆分与压缩

对于极端大量的数据，可以考虑不再导出单一Excel文件，而是导出多个压缩包（如每10万行一个Excel，然后打包成ZIP）。但这更多是业务逻辑的变更。

2.4 总结

立即止损（线上紧急情况）：
- 短期：如果正在频繁OOM，可以先增大堆内存 -Xmx 并重启服务，快速恢复业务。
- 同时：在网关/应用层紧急添加导出限流策略，防止问题复发。
根本解决（中期必须完成）：
- 改造代码 ：将导出逻辑从使用HSSFWorkbook/XSSFWorkbook迁移到SXSSFWorkbook。
- 优化数据查询 ：确保数据获取是分页的，而不是一次性加载。
优化体验与架构（长期规划）：
- 改为异步导出，并提供任务查询界面。这是对用户和最系统都最友好的方式。
- 考虑将生成的大文件存储到OSS等对象存储中，减轻应用服务器磁盘IO压力。

技术选型参考

首选：SXSSF + 分页查询 + 异步导出。
备选：如果数据模型非常简单，也可以考虑直接生成CSV文件，CSV是纯文本格式，内存开销远小于Excel。但缺点是无法处理样式和多个Sheet。