Java Files.readString 读取大文件为什么会撑高堆：内存预算与分块读取边界

批量导入任务偶尔在读取一份几百 MB 的日志时突然出现堆占用飙升，问题往往不在 GC 参数，而在入口就调用了 Files.readString(path)。这个方法会把文件全部解码成一个 String，适合配置文件、模板等小文本；面对大文件，应按行或按固定块消费，并让处理逻辑尽快释放中间对象。

Files.readString 读取单个文件的堆总开销，不是等于文件的磁盘占用大小，还要加上字符解码、内部临时字节数组的额外内存，实际峰值占用一般是原文件体积的1.5到2倍，没有提前做内存预算的话，很容易触发堆溢出。

Files.readString 为什么会让堆占用突然变高

Files.readString 的语义很直接：读取文件全部内容并按指定字符集解码为字符串。文件先要有字节缓冲，解码过程还要生成字符数据，最终业务代码通常又会把这个字符串切分、解析或转换成对象。因此，不能把“文件大小”简单当成“只占同样大小的堆”。

例如一个 300 MB 的 UTF-8 日志，如果随后用正则或 split 生成行数组，短时间内可能同时存在原始字符串、切分结果和正在构造的业务对象。并发跑 4 个任务时，单任务看似还能接受的峰值也会被放大。

先算单任务预算，再决定读取方式

可以先用一个保守估算判断是否值得整读：

单任务预算 ≈ 文件字节数 × 解码与中间对象系数 + 业务对象峰值
并发预算 ≈ 单任务预算 × 同时处理的文件数 + JVM 基础占用

这里的系数不是 JVM 规范中的固定常数，而是压测得到的工程参数。中文内容、短字符串数量、解析器临时对象都会改变峰值。若预算已经接近 -Xmx 的安全线，就不要再用一次性字符串作为入口。

小文件继续整读，大文件改成 BufferedReader

配置文件、单个模板或几十 KB 的规则文本，整读代码最清楚：

Path path = Path.of("config/rules.txt");
String rules = Files.readString(path, StandardCharsets.UTF_8);
RuleSet ruleSet = RuleSet.parse(rules);

当文件变大且业务可以逐行处理时，使用 newBufferedReader 把“读取一行”和“处理一行”放在同一个循环里：

long accepted = 0;
try (BufferedReader reader = Files.newBufferedReader(
        path, StandardCharsets.UTF_8)) {
    String line;
    while ((line = reader.readLine()) != null) {
        LogRecord record = LogRecord.parse(line);
        if (record.isAccepted()) {
            save(record);
            accepted++;
        }
    }
}
System.out.println("accepted=" + accepted);

这段写法的重点不是把所有内容变小，而是让业务不再持有整个文件的字符串。若 save 又把记录积累进一个无界集合，内存问题仍然会回来，所以消费端也要有批量提交或背压边界。

固定块读取适合没有稳定换行的数据

二进制文件、超长单行或需要自定义分隔符时，可以使用 InputStream 配合固定大小的字节数组。每次读取后立即处理，跨块的半条记录放进一个有上限的拼接缓冲，并对异常长度做拒绝或转存，避免某一条坏数据无限增长。

Files.lines 的便利和关闭边界

Files.lines(path) 返回惰性行流，适合把过滤和计数写得简洁，但它持有底层文件资源。正确姿势是放进 try-with-resources：

long errorCount;
try (Stream lines = Files.lines(path, StandardCharsets.UTF_8)) {
    errorCount = lines.filter(line -> line.contains("ERROR")).count();
}

不要把这个流存到字段里等以后再消费，也不要只依赖 GC 关闭文件。短命任务要在代码边界内完成关闭，长时间运行的批处理尤其要记录打开文件数和异常路径。

用三个检查点验证改造真的有效

压测时不要只准备一个“平均大小”的文件。至少加入小文件、接近预算上限的文件、空文件、超长行和编码异常文件，分别记录结果。这样才能分辨是读取策略不合适，还是解析器本身在缓存数据。

常见问题

Files.readString 读取 2GB 文件一定会报错吗？

不应把它当作可靠方案。Java 文档明确提醒该方法不面向超大文件，极大文件可能触发 OutOfMemoryError；即使当前机器勉强读入，也会给并发任务留下很小的余量。

Files.readAllLines 和 readString 哪个更省内存？

两者都属于一次性读取思路，readAllLines 还会创建行集合。真正需要控制峰值时，优先改为 newBufferedReader 或受控的块读取。

使用 BufferedReader 后还要手动 close 吗？

使用 try-with-resources 即可自动关闭；不要把 reader 交给不清楚生命周期的异步任务。若跨线程传递，先重新设计资源边界。

为什么改成流式读取后堆仍然持续上涨？

重点检查下游是否把记录放进无界 List、缓存 key 是否带文件内容、批量提交是否没有清空，以及异常记录是否被重复保留。读取端省下的内存可能被消费端重新占满。

小结

Files.readString 的问题不是“不能用”，而是它把文件完整内容带进了当前任务的内存边界。小文本可以保持简单；大文件则应按行、按块或交给外部流式处理，并用堆峰值、吞吐和资源关闭三项结果验收。先做预算，再选 API，通常比事后调大堆更稳。