Java 批量导出报表怎么避免内存爆掉：游标读取、分片写入与断点续传

线上订单报表导出耗时突然从两分钟涨到十几分钟，监控里最先异常的不是数据库CPU，而是导出接口的老年代占用一路走高。排查后发现，原代码先把几十万行订单数据全部塞进 List，再交给Excel写入组件统一输出；数据量越大，内存峰值冲得越高，最终在几次Full GC之后直接抛出OOM。

大批量导出的核心优化思路，就是把全量数据的生命周期彻底拆解开，全程保持流式读取、分片写入，进度状态落地持久化，就能完全绕开全量加载导致的内存溢出问题。

先看现场：为什么简单的List会把导出任务拖垮

新手最容易写出来的初版导出逻辑大多是这样：查询方法直接返回一个全量集合，业务层把集合里的每条数据映射成导出行，最后一次性写入Excel工作簿。这个写法在几千行数据时跑着很顺畅，但放到订单、流水、设备日志这类数据量持续上涨的表上，会同时在内存里保留数据库驱动缓冲区、Java业务对象、字符串字段和Excel写入组件的临时行缓存，几层内存叠加很快就把堆打满。

List rows = orderDao.findByRange(from, to);
List exportRows = rows.stream()
        .map(ExportRow::from)
        .toList();
excelWriter.write(exportRows);

这里至少有三层对象生命周期完全重叠：查询结果集还没释放，映射好的业务对象已经全部创建完毕，写入组件又可能维护自己的行级缓存。如果堆快照里能看到大量 String、byte[] 和导出行对象，先别急着调大 -Xmx 的上限，那只是把OOM的触发时间往后推迟而已，根本问题没解决。

把读取端改成游标：内存里每次只保留一个很小的数据窗口

导出任务本质上只需要做到读一行、处理一行、写一行，完全没必要等全量数据读完再开始后续步骤。JDBC层可以用只读连接、服务端游标和合适的 fetchSize 来限制内存里的预取窗口大小。不同数据库驱动的默认行为差异很大，不能只改一个参数就默认已经开启流式读取。

String sql = "select id, user_id, total_amount, created_at "
        + "from orders where created_at >= ? and created_at 

fetchSize=1000 只是参考起点，不是所有场景下都通用的正确答案。单条字段很宽的时候窗口要设得更小，网络延迟高、单条数据体量很小的时候可以适当把数值调大。压测的时候同时看堆内存曲线、数据库侧游标数量和单片文件的写入速度，三个指标都稳定才是合理的参数。

不要把所有数据塞到同一个文件里：用分片保存进度

读取端改成流式之后，文件写入侧也要配套做边界拆分。比较实用的做法是每攒够50000行或者文件大小达到32MB，就关闭当前正在写入的分片，写好完成标记之后再新建下一个分片。任务表只保存整体状态和最后一个已完成的分片编号，不需要把每一行数据的状态都写到数据库里。

分片写完之后先落到磁盘上的临时文件名，比如 part-0007.csv.writing，调用flush刷盘、关闭文件流、校验完文件大小和摘要之后，再原子性改名为正式的 part-0007.csv。服务意外重启的时候只需要清理目录里的 .writing 文件就好，已经写完的分片可以直接复用，不需要重新生成。

任务状态要支持可恢复：失败后只需要重做缺口部分

导出任务不能依赖内存里的变量来记录进度。下面这几个状态值就足够支撑一个可恢复的导出版本：CREATED、RUNNING、PAUSED、SUCCEEDED 和 FAILED。状态变更和分片完成记录必须保证先后顺序，不能分片文件还没完全关闭落盘就提前把分片标记为已完成。

public void markPartReady(String taskId, int partNo, Path temp, Path ready) {
    verifySize(temp);
    verifyDigest(temp);
    moveAtomically(temp, ready);
    partRepository.saveReady(taskId, partNo, Files.size(ready));
}

如果进程在文件原子改名完成之后、数据库状态更新之前意外退出，启动恢复逻辑的时候可以直接扫描存储路径下的文件，根据文件名和摘要补写对应分片的状态；如果是在改名之前退出，直接删掉不完整的临时文件就行。这个执行顺序让“文件已经存在但数据库没标记完成”变成可以自动修复的状态，反过来的话就很容易出现用户下载到半截损坏的文件。

断点续传不是简单从偏移量拼文件：先核对文件版本

下载接口单纯支持返回部分内容 Accept-Ranges: bytes 是不够的。客户端发起断点续传请求带过来的 Range 必须和当前文件的 ETag 做绑定校验；如果同一个任务之前重新生成过全量文件，旧文件的偏移量不能直接套到新文件上做续传。

String etag = digestStore.get(taskId);
if (!etag.equals(request.getHeader("If-Range"))) {
    return fullResponse(currentFile, etag);
}
Range range = Range.parse(request.getHeader("Range"), fileSize);
return partialResponse(currentFile, range, etag);

服务端续传逻辑要先校验请求的起始偏移量小于文件总大小、结束偏移量不超过文件总大小，并且在响应头里带上 Content-Range。已经过期的导出任务直接返回410状态码，比默默返回一段新文件内容更容易让客户端做兼容处理。

上线前用三个梯度的数据量做回归验证

不要只拿一万行数据跑通功能就直接上线。至少准备1万行、50万行和超过单片阈值的三组测试样本，分别验证堆占用、首字节响应时间、分片写入耗时、失败自动恢复和下载完整性校验几个环节。预期效果不是内存完全没有波动，而是内存峰值只和单fetch窗口大小、当前正在写入的分片体量相关，不会随着导出总行数的增长线性上涨。

• 内存：连续导出50万行数据时老年代不会持续无限制爬升，Full GC之后内存占用可以回落至正常区间。
• 数据库：游标关闭后连接正常归还连接池，任务主动取消之后不会留下长期占用的数据库连接。
• 文件：随机删掉一个还没完成的分片文件，恢复导出任务之后只会重新生成缺失的这一个分片。
• 下载：下载中途断开后带上原文件的ETag发起续传，最终得到的完整文件SHA-256摘要和服务端预存的摘要完全一致。

常见问题：导出任务还有哪些容易踩的边界坑

fetchSize设置得越大，导出速度就一定越快吗？

不一定。大的fetchSize会减少数据库和应用层的网络往返次数，但也会同步增大驱动侧的缓存占用和单次数据等待时长，最终还是要以堆峰值、数据库响应延迟和分片写入速度的平衡点作为设置标准。

为什么不直接把所有CSV分片在内存里合并成一个完整文件？

可以在全部分片写完之后增加一个合并阶段，但合并阶段不要把所有分片的内容重新全部读进内存。直接按字节流顺序拼接就行，同时保留每个分片的原始摘要，后续文件出问题的时候更容易定位出错的分片位置。

任务中途取消的时候需要回滚正在执行的数据库查询吗？

核心逻辑是按顺序关闭ResultSet、Statement和Connection这几个资源，并且清理掉未完成的临时文件。导出场景本身用的都是只读查询，不需要为了取消任务特意去做耗时很长的大事务回滚。

什么场景下应该把同步导出改成异步导出？

当导出查询耗时可能超过接口请求超时时间、生成的文件需要支持多次下载，或者用户需要中途查看导出进度的时候，就可以把数据读取和文件生成环节拆成异步后台任务，单独用进度查询接口承接前端的状态查询请求。

总结：让总数据量不再直接决定堆内存大小

这次改造的核心调整点不是某个Excel写入库的冷门参数，而是把全量数据的生命周期彻底拆解开：数据库游标提供固定大小的读取窗口，分片文件承接最终落地的结果数据，任务状态表记录可恢复的进度信息，ETag机制约束断点续传的文件版本。先把“一次性加载全量集合”的逻辑从整个链路里移除，再根据压测结果调整fetchSize、分片行数和并发任务数，导出接口的内存占用才能在业务数据持续增长之后依然保持可控。