Java千万级CSV导出内存溢出？流式查询+缓冲写入解法

简介：面向中高级Java开发者，这份资源围绕千万级数据量的CSV导出场景，针对一次性加载导致的内存溢出与性能瓶颈，提供了完整的优化方案与可直接运行的示例代码。压缩包共十个文件，其中九个Java源文件覆盖分批处理、多线程并行写入、线程池管理、内存映射等核心实现，另有一个txt文档简述设计思路与注意事项，资源总大小仅十KB，轻量便于阅读。目前已有15562人学习下载，其设计思路在批量导出场景中有较高参考价值。读者可以从中掌握利用缓冲流逐行读写、按十万条分块配合线程池避免内存溢出的关键做法，以及通过内存映射文件进一步降低内存占用、保障系统稳定的具体方法，并参考异常捕获、日志监控等稳定性设计，直接应用到生产环境的批量导出任务中。

1. 导出千万级CSV老是被内存溢出打断：这个坑几乎每个Java后端都踩过

一个典型的翻车现场：线上报表导出功能，数据库里 900 多万行数据，点一下「导出」，页面转圈三分钟，接口直接抛java.lang.OutOfMemoryError: Java heap space，服务跟着重启。把 JVM 堆内存从 2G 调到 4G 再试，照样炸。这就是 Java 做 CSV 大数据量导出最折腾人的地方：问题不在堆给得不够，而是代码把千万行数据全塞进了内存再统一写文件。

这篇文章写给正被同类问题卡住的后端开发者——做过报表导出、数据迁移、对账文件生成，被 OOM 折磨过或正在被折磨。解决思路其实就一句话：查询走流式，写入走缓冲，堆里同一时刻只允许存在一小批数据。下面按「为什么炸 → 怎么改 → 避坑」的顺序把整个方案讲透。

2. 为什么导出千万级CSV会内存溢出：三个藏在代码里的根因

先把最常见的「错误写法」摆出来。很多人的导出代码长这样：

// 危险写法：只适合几千行的数据 List<User> users = userMapper.selectAll(); // 一会儿把所有行都装进堆 StringBuilder sb = new StringBuilder(); for (User u : users) { sb.append(u.getId()).append(',').append(u.getName()).append('\n'); } Files.write(Paths.get("users.csv"), sb.toString().getBytes(StandardCharsets.UTF_8));

这段代码在数据量小的时候没有任何问题，数据量一旦到百万、千万，堆就肉眼可见地告急。下面三个根因，基本解释了为什么它必炸。

2.1 根因一：一次查询把所有行装进List，堆被对象头和数据双重吃光

先算一笔账。假设导出的表有 1000 万行，每行 5 个字段：id（Long）、name（String）、age（Integer）之类。selectAll()执行完，堆里至少多出这么几块东西：

• List 的引用数组：1000 万条引用，按压缩指针 4 字节算，约 40MB；
• 每一行的实体对象：一个 User 对象光是对象头加字段对齐就要 16 字节起步，加上 Long、Integer 这些包装类型各自的 16 字节对象头，单行 50～80 字节很常见，1000 万行就是 500～800MB；
• name 字段的字符串：每个 String 对象有 16 字节头 + char[] 引用，char[] 里每个字符 2 字节。一个 10 个字符的名字，char[] 加对象头大约 40 字节，1000 万行又是 400MB；
• 后面sb.toString()和getBytes()还会再复制一整份。

也就是说，光是把数据查出来，堆里就已经多了 1～2GB 的占用。JVM 堆开 1G、2G 根本不够看，开到 4G 也就是延缓死刑。这里有个反直觉的点：真正吃掉内存的不只是「数据本身」，还有大量看不见的对象头、包装类型、char[] 对齐填充。

那有人会说：我不用 List，我用分页，每页 1000 行循环查。这在几万行时可行，到千万级同样难受——LIMIT 5000000, 1000这种深分页，数据库每次都要从头扫描到第 500 万行再丢弃，越到后面越慢，整个导出时间膨胀到不可接受。而且如果循环里又把每一页数据累计到一个大 List 去排序、去重，内存最终还是被堆满。深分页解决的是「界面翻页」问题，解决不了「全量导出」问题。

2.2 根因二：StringBuilder无脑拼接和字符集转换，制造了大量重复对象

上面那段错误代码里，StringBuilder也不是省油的灯。append过程中底层 char[] 会按 1.5 倍左右的倍率扩容，每次扩容都要把旧数组复制一遍。当拼接目标是几百 MB 的字符串时，扩容瞬间会同时存在新旧两份大数组，GC 压力瞬间拉满。

更隐蔽的是sb.toString().getBytes(StandardCharsets.UTF_8)这一步。toString()会把整个 StringBuilder 的 char[] 再复制一份给 String，getBytes()再按 UTF-8 编码出一份 byte[]。也就是说，最终写文件的那一下，堆里同时存在：char[] 原数组、String 内部的 char[]、byte[] 三份超大对象。一次导出 500MB 文本，这一步就可能瞬时多出 1GB 内存占用。

字符串拼接在循环里还有一个经典翻车写法：

String line = u.getId() + "," + u.getName() + "\n"; // 循环内每行一个匿名StringBuilder

每执行一次，都会 new 一个 StringBuilder、生成若干个临时 String。千万行就是千万次小对象创建，minor GC 频率暴涨，最后通常跟出java.lang.OutOfMemoryError: GC overhead limit exceeded——这行报错不是堆给少了，是 JVM 花了 98% 的时间在 GC 却只回收了 2% 的内存，典型「大量小对象 + 无效拼接」症状。

我对付这类问题的原则很简单：数据在业务层只做「读取一行 → 拼一行 → 写一行」，绝不在内存里把全部文本攒起来。任何一步「先全部拼好再写」的设计，都是把 OOM 的倒计时调快了。

2.3 根因三：fetchSize 没生效，数据库驱动还在默默缓存所有行

很多人知道要「流式查询」，于是在 PreparedStatement 上调用了setFetchSize(1000)，但内存照样爆。原因是：JDBC 驱动默认不开启流式，fetchSize在某些数据库上直接被忽略，结果集仍然被一次性全部拉回客户端内存。

这事的坑特别多，先说常见关系型数据库的两类差异：

• MySQL 的 Connector/J 驱动：默认执行查询时，服务端把所有结果一次性发给客户端，setFetchSize(int)必须在连接串上显式开启useCursorFetch=true才会走服务端游标；在 5.x 老驱动里，还得配合ResultSet.TYPE_FORWARD_ONLY并把fetchSize设为Integer.MIN_VALUE，驱动才会退回流式协议。
• PostgreSQL 的 JDBC 驱动：fetchSize的生效有硬性前提——连接必须setAutoCommit(false)。如果开着自动提交，驱动会认为查询是一次性事务，仍然全量读取结果集，fetchSize形同虚设。

看到这你大概明白了：报错信息一模一样，但根因可能各不相同。调了 fetchSize 还 OOM 的，十有八九是「以为配置生效了，实际驱动根本没走流式」。这个黑匣子如果不拆开，换大堆内存、换机器都是在赌运气。

3. 边查边写：游标流式读取 + 缓冲流分批落盘，千万行导出内存稳如老狗

3.1 核心原理：游标结果集省内存的本质

流式读取的机制可以简单理解成：传统模式下，驱动执行完查询就把所有结果行缓存到客户端内存里；流式模式下，驱动只在客户端保留一个游标位置，调用一次rs.next()才从服务端取下一行，取到一批（fetchSize 大小）之后再触发下一次网络拉取。堆里同一时刻最多只存在一批行，而不是全部行。

所以导出千万行 CSV 的正确姿势是两条腿走路：查询端用流式 ResultSet 控制「堆里最多有多少行」，写入端用带缓冲的 Writer 控制「磁盘最少写多少次」。查询每一批最多 1000 行，写入每攒够 1MB 再落盘一次，整个导出的内存占用就能稳定在一个很低的水平。

注意，流式模式下 ResultSet 连接是长时间占用的，所以这段代码必须在同一个事务里跑完，中途不能把连接还给连接池。这也是为什么 MyBatis 里用Cursor时，官方反复强调要在 SqlSession 未关闭的范围内遍历游标。

3.2 可直接运行的完整示例：JDBC 游标 + CSV 转义 + UTF-8 BOM

下面这份代码是完整的、可以直接放进项目里的方法。

import java.io.BufferedWriter; import java.io.FileOutputStream; import java.io.OutputStreamWriter; import java.nio.charset.StandardCharsets; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import javax.sql.DataSource; /** * 千万级CSV导出：游标流式读取 + 缓冲流分批落盘 * 适用场景：支持服务端游标的关系型数据库 */ public class CsvBigExport { public static void exportBigCsv(DataSource dataSource, String sql, String filePath) throws Exception { try (Connection conn = dataSource.getConnection()) { // 关键1：关闭自动提交。PostgreSQL 必须这样 fetchSize 才生效 conn.setAutoCommit(false); try (PreparedStatement ps = conn.prepareStatement( sql, ResultSet.TYPE_FORWARD_ONLY, // 只允许向前读 ResultSet.CONCUR_READ_ONLY)) { // 只读结果集 // 关键2：每批拉取的行数，配合驱动开启服务端游标 ps.setFetchSize(1000); try (ResultSet rs = ps.executeQuery(); // 关键3：1MB 缓冲，攒够一批再刷盘，减少磁盘IO次数 BufferedWriter writer = new BufferedWriter( new OutputStreamWriter( new FileOutputStream(filePath), StandardCharsets.UTF_8), 1024 * 1024)) { // 关键4：UTF-8 BOM，避免 Excel 打开中文乱码 writer.write('\uFEFF'); writer.write("id,name,age,remark\n"); while (rs.next()) { // 每一行一个小的StringBuilder，拼完即弃，不累积 StringBuilder line = new StringBuilder(128); line.append(rs.getLong("id")).append(',') .append(csvEscape(rs.getString("name"))).append(',') .append(rs.getInt("age")).append(',') .append(csvEscape(rs.getString("remark"))).append('\n'); writer.write(line.toString()); } writer.flush(); } } finally { // 关键5：恢复默认状态，避免连接池里其他线程拿到异常事务 conn.setAutoCommit(true); } } } private static String csvEscape(String value) { if (value == null) { return ""; } // 字段里含逗号/双引号/换行时必须用双引号包裹 if (value.indexOf(',') >= 0 || value.indexOf('"') >= 0 || value.indexOf('\n') >= 0 || value.indexOf('\r') >= 0) { // 内部的双引号转义为两个连续双引号 return '"' + value.replace("\"", "\"\"") + '"'; } return value; } }

几个参数逐个说明：

• ResultSet.TYPE_FORWARD_ONLY和CONCUR_READ_ONLY：流式读取的硬性前提。如果用默认参数创建 Statement，部分驱动会退回全量缓存模式。这个细节网上很多例程没写，漏掉它，setFetchSize等于白设。
• ps.setFetchSize(1000)：每次从数据库拉取 1000 行。取值不是越大越好，也不是越小越好。太小了网络往返次数暴涨，导出一千万行要发一万次请求；太大了流式优势被稀释。我一般取 1000～5000 之间，视单行字段宽度调整。
• BufferedWriter的 1MB 缓冲：写入端每攒 1MB 才真正调用一次 IO。如果没有这层缓冲，每行一次磁盘写，千万行就是千万次 IO，导出时间会从分钟级拖到小时级。
• writer.write('\uFEFF')：BOM 头只能写在文件最前面且只能写一次。它是给 Excel 认编码用的，写在中间反而会产生不可见字符。

提示：MySQL 8.x 的注意点是连接串必须带useCursorFetch=true，代码里的setFetchSize(1000)才会被驱动认可；两个缺一个，查询都会退化为全量缓存。5.x 老驱动则把setFetchSize(1000)改成setFetchSize(Integer.MIN_VALUE)，这是老驱动触发流式协议的标志值。两种写法不要混用。

3.3 MyBatis 用 Cursor 的写法与三个注意事项

如果你项目里用的是 MyBatis，不一定要手写 JDBC。Mapper 方法返回类型从List<User>改成Cursor<User>，底层走的还是 JDBC 流式结果集：

// Mapper 接口声明 Cursor<User> selectAllByCursor();

// Service 中使用：游标必须在 SqlSession 存活时间内遍历完 try (SqlSession sqlSession = sqlSessionFactory.openSession(); Cursor<User> cursor = sqlSession.getMapper(UserMapper.class).selectAllByCursor()) { for (User user : cursor) { // 逐行写入文件 writer.write(...); } }

用 Cursor 有三个坑要提前知道。第一，sqlSessionFactory.openSession()不要传自动提交，保持手动控制；第二，遍历结束后再关 SqlSession，绝不能先关连接再遍历游标，否则会抛ResultSet is closed之类的异常；第三，Mapper XML 里如果写了fetchSize="1000"，需要确认数据库驱动支持，MySQL 同样依赖连接串的useCursorFetch=true。本质上 Cursor 只是把 JDBC 的流式查询包了一层，前面讲的驱动配置它一个都躲不掉。

3.4 参数选型与压测建议

把上面几个参数放在一起看，它们各自管一段瓶颈：

拿到参数之后，我建议做一次「先小后大」的压测：先用limit 100000导出 10 万行，观察耗时和内存；再用全量跑一千万行，同时用监控工具盯堆内存。如果 10 万行时堆就明显上涨，先回去查 fetchSize 是否生效，不要急着加-Xmx。加堆内存是最后的兜底手段，不是第一解决方案——你永远不知道下一个项目的数据量会不会翻倍。

4. 导出文件乱码、列错位、连接断掉：五条高频踩坑记录

这一章全是我和同行踩过的真实翻车记录，每条按「现象 → 原因 → 解决」拆开，方便你对号入座。

4.1 现象：导出的 CSV 用 Excel 打开，中文全是乱码

现象是文件在 Notepad、IDE 里看是正常的，一用 Excel 打开，中文变成「鏂囨。鎺掗敊」之类的乱码。

原因：CSV 文件本身是 UTF-8 编码，但 Excel 打开无 BOM 的 UTF-8 文件时，会按本地系统编码（中文系统里是 GBK）去解读，编码对不上就乱码。

解决：写文件时在最开头写入一个 BOM 头\uFEFF，Excel 看到 BOM 就会按 UTF-8 解析。上面示例代码里writer.write('\uFEFF')就是干这个的。如果明确知道使用者只会用 Excel 打开，也可以直接把文件按 GBK 输出，但 BOM 方案兼容性最好。注意 BOM 一定要在写任何数据之前写入，且全文件只能出现一次。

4.2 现象：长数字 ID 变成科学计数法，精度丢失

现象：数据库里的雪花 ID 是 19 位数字，导出到 CSV 后用 Excel 打开，显示成1.23457E+17，后几位变成了 0。

原因：Excel 对超过 15 位的纯数字默认按数值处理并转成科学计数法，超过 15 位之后的精度直接丢弃。这不是 CSV 规范的问题，是 Excel 的显示逻辑。

解决：在需要保留精度的数字列后面拼一个制表符\t，让 Excel 判断这一列不是纯数字，从而按文本显示：

writer.write(csvEscape(String.valueOf(rs.getLong("id"))) + "\t,"); // 数字后补制表符，Excel 按文本处理

注意这里的顺序：数字 + "\t"再接逗号，逗号仍然是字段分隔符。如果 CSV 最终不是给 Excel 用的，这招会多出一个制表符，所以只在确认使用者用 Excel 打开时用。另一种做法是把单元格写成="1234567890123456789"的公式形式，Excel 会显示为文本，但对其他解析器不友好，我不太推荐。

4.3 现象：字段里带逗号、换行，导出后列错位

现象：某一行数据里有个字段存的是多行文本（比如备注），导出后 Excel 里这一行被拆成了两行，后面的列全部右移。

原因：CSV 规范规定，字段内如果包含逗号、双引号、换行符，整个字段必须用双引号包裹，字段内部的双引号用两个连续双引号转义。很多初版实现只处理了逗号，漏了换行和双引号。

解决：上面示例里的csvEscape方法就是标准处理。核心判断条件不要漏：

if (value.indexOf(',') >= 0 || value.indexOf('"') >= 0 || value.indexOf('\n') >= 0 || value.indexOf('\r') >= 0) { return '"' + value.replace("\"", "\"\"") + '"'; }

顺便说一个常见误用：有人在replace里先处理了逗号再处理双引号，结果把转义规则搞乱。正确的顺序是「先判断是否需要包裹，再统一替换双引号」，不要分两步处理。写完之后用一个带逗号、换行、双引号的测试样本验证一下，这比任何理论都可靠。

4.4 现象：导出到一半报 Connection reset，任务直接失败

现象：导出小数据量没问题，一跑千万级，执行到 70% 左右抛Communications link failure或Connection reset by peer，看数据库端日志发现连接被服务端主动关闭。

原因：大导出期间结果集游标长时间占用连接，而数据库、负载均衡设备或防火墙对空闲连接有默认超时（常见 30～60 秒）。虽然数据一直在传，但在某些中间设备看来，这条连接长时间没有「新的查询活动」，就被当作空闲连接回收了。

解决：给连接串显式配置更大的超时时间。常见的是连接串上加socketTimeout（单位毫秒），把它调大到能覆盖整个导出时长；同时确认数据库侧的wait_timeout/idle_in_transaction_session_timeout足够大。注意这个参数对「一次查询内持续拉取」同样有效，它卡的是 socket 级别的读超时。我一般直接设 10 分钟起步，导出完再排查会不会话悬挂，而不是让大导出卡死在中途。

4.5 现象：fetchSize 配了，内存还是涨到溢出

现象：代码里明明写了ps.setFetchSize(1000)，导出过程中用监控工具看堆内存，Old 区还是匀速上涨，最终 OOM。

原因通常是下面几种之一，按出现频率排：

1. MySQL 8.x 驱动没在连接串里加useCursorFetch=true，setFetchSize被忽略；
2. 用的是老驱动却把 fetchSize 设成了正数 1000，而不是Integer.MIN_VALUE；
3. MyBatis 的 Mapper 方法返回类型还是List<User>，而不是Cursor<User>，查询结果被全部缓存；
4. 代码里虽然流式读取了，但把每一行对象又收集到另一个 List 里统一排序、去重后再写文件，等于绕了一圈又回到全量加载。

解决：逐条对照排查。最直接的办法是打印驱动日志确认每次网络请求带回的行数；更省事的是做一个小实验——把 fetchSize 改成 10，导出 100 万行，如果内存还是爆，说明流式根本没生效，因为 10 行一批的模式下堆里不可能堆下几百万行对象。这个「把参数改极端再验证」的技巧，能帮你快速区分是配置问题还是代码问题。

5. 快速定位导出异常：一张报错对照表和三步验证法

导出 CSV 的报错看着五花八门，归纳下来就那么几类。先给一张我排查时常用的对照表：

对照表里最容易被忽视的是「fetchSize 是否真的生效」。我见过太多人配置写了、代码没写全，比如漏了TYPE_FORWARD_ONLY，或者连接串少了参数，症状和没配置完全一样。所以我把验证方法固定成三步，每次遇到导出相关故障都按这个顺序走。

第一步，小样冒烟测试。先给查询加LIMIT 100000，导 10 万行确认文件内容、编码、转义全对。这一步能过滤掉绝大部分业务逻辑错误，把问题范围缩小到「数据量导致的」还是「逻辑导致的」。

第二步，观察内存曲线。导出过程中用jstat -gcutil <pid> 1000每隔一秒打一次 GC 状态，重点看 Old 区的占用曲线。如果 Old 区随导出匀速上涨、Full GC 次数增加，基本可以断定查询端在往堆里堆数据；如果内存平稳，文件也在持续变大，那就是写入端或超时的问题。这一步能直接区分「查询端」和「写入端」两个嫌疑方向。

第三步，看磁盘文件的增长。导出过程中用ls -l盯输出文件大小，文件在持续增长说明主循环在正常推进。如果文件涨但内存也涨，问题在查询端；如果文件完全不涨、接口卡死，问题多半在查询句柄或事务配置上，比如游标没有真正被遍历。

顺手再说一个细节：文件导出完一定记得看「文件大小和行数是否匹配」。用wc -l数一下行数，和数据库里的COUNT(*)对得上，再交付。行数不对的半成品文件发出去，比不发更麻烦。

从那以后，我每次写导出功能都强制自己先过四道问：数据量级是多少、能不能走流式、文件最终给谁看、特殊字符和编码处理了没。四个问题答完再动手写代码，这个习惯帮我挡住了后面至少三次翻车。如果你现在正被 OOM、乱码、连接断开轮流折磨，按上面的对照表和验证三步走一遍，大概率能在半小时内定位到根因。希望帮到你。

本文还有配套的精品资源，点击获取