Java Files流式读取大文件

大文件读取最容易出现的故障，不是“文件打不开”，而是代码把一个本应逐行处理的任务写成了整文件加载：导入几百 MB 的日志后，堆占用持续上涨，GC 变得频繁，最后甚至出现 OutOfMemoryError。如果入口是 Files.readAllLines，根因通常很明确：它返回的是包含全部行的 List，文件越大，内存压力就越直接。

更合适的修复是让文件内容保持流式：需要明确循环和异常边界时用 Files.newBufferedReader，适合接入 Stream 管道时用 Files.lines。两者都不是“无限吞吐”开关，仍然要处理字符集、单行大小、文件变化和资源关闭。

官方地址：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/file/Files.html

结论：大文本文件不要先调用 readAllLines 再筛选；先选定字符集，再用 newBufferedReader 或 Files.lines 逐行消费，并把读取对象放进 try-with-resources。

先从内存上涨症状定位到读取入口

一次批量导入任务的时间线通常是这样的：小样本时很快完成；文件变大后，进程堆占用跟着文件大小上升；业务处理本身没有明显变复杂，但 GC 次数和暂停时间增加；最后，真正的业务逻辑还没开始，程序已经在搬运字符串对象。

触发条件不是“Java 不能读大文件”，而是读取 API 的结果形态不适合当前任务。Files.readAllLines(path, charset) 会把全部行收集成一个列表，适合文件确实不大、且后续需要随机访问所有行的场景。对大日志、导入文件和归档文本，完整列表会把输入大小直接传导到堆内存。

修复动作应先改变数据形态，而不是先调大堆。Path.of 只表示路径；Charset 负责字节到字符的解释；newBufferedReader 返回可循环读取的 BufferedReader；Files.lines 返回延迟读取的 Stream。它们的职责不同，不能把“流式”理解成只换一个方法名。

用 BufferedReader 按行读取大文件

需要在每一行上做条件判断、解析字段或累计有限结果时，Files.newBufferedReader 往往最直观。它可以显式指定字符集，读取器实现了 AutoCloseable，放进 try-with-resources 后，正常结束和异常退出都能释放文件资源。

import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

public final class LargeFileReader {
    private LargeFileReader() {
        // 工具类不保存共享状态，避免把读取上下文藏在静态字段里。
    }

    public static long countMatchingLines(Path path, Charset charset, String keyword)
            throws IOException {
        long matched = 0;
        try (BufferedReader reader = Files.newBufferedReader(path, charset)) {
            String line;
            while ((line = reader.readLine()) != null) {
                // 只保留计数，不把全部行收集进内存。
                if (line.contains(keyword)) {
                    matched++;
                }
            }
        }
        return matched;
    }

    public static void main(String[] args) throws IOException {
        Path path = Path.of("access.log");
        long result = countMatchingLines(path, StandardCharsets.UTF_8, "status=500");
        // 这里的输出只是示例结果处理，不代表本文已在本机执行。
        System.out.println("匹配行数：" + result);
    }
}

这个写法的关键不是 BufferedReader 这个名字，而是处理函数没有把每一行追加到全局列表。内存主要承载当前行和少量业务状态，峰值不会因为文件总行数线性增加。当然，如果某一行本身极长，当前行仍可能占用较多内存；“逐行”不等于“每次只占固定几个字节”。

字符集必须和文件实际编码一致。无参的 Files.newBufferedReader(path) 按 UTF-8 工作；如果上游文件是其他编码，应使用带 Charset 的重载，而不是依赖操作系统默认值。Oracle API 还说明，遇到 malformed 或 unmappable 字节序列时，读取方法会抛出 IOException，所以不能把乱码问题归咎于缓冲区大小。

用 Files.lines 延迟消费，而不是忘记关闭 Stream

如果处理逻辑天然是过滤、映射、计数或查找，Files.lines 可以直接提供 Stream。它不会像 readAllLines 一样先建立完整列表，而是在 Stream 被消费时按需读取。

import java.io.IOException;
import java.io.UncheckedIOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

public final class LineStreamReader {
    private LineStreamReader() {
        // 不允许实例化，示例只提供静态读取方法。
    }

    public static long countErrorLines(Path path) throws IOException {
        try (var lines = Files.lines(path, StandardCharsets.UTF_8)) {
            // Stream 持有打开的文件，必须和 try-with-resources 绑定。
            return lines.filter(line -> line.contains(" level=ERROR "))
                    .count();
        } catch (UncheckedIOException ex) {
            // Stream 消费阶段的 I/O 异常会包装成 UncheckedIOException。
            throw ex;
        }
    }
}

这里的 try 不能省略。Oracle 文档明确说明，返回的 Stream 引用了打开的文件，关闭 Stream 才会关闭文件；API 也建议使用 try-with-resources。仅仅依赖终端操作结束或垃圾回收，会让文件句柄的释放时机变得不可控。

还要区分异常发生的位置：打开文件时可能直接得到 IOException；Stream 真正读取或终端消费时，后续 I/O 异常和解码异常可能以 UncheckedIOException 形式出现；关闭阶段如果失败，同样可能被包装。调用方要根据自己的接口边界决定是继续抛出、转换成业务错误，还是记录文件路径后终止任务。

字符集与异常边界不能省略

大文件故障修复后，第二类隐蔽问题通常出现在“文件能读但内容不对”：中文字段被替换符号代替，某些行解析失败，或者处理到文件中段才抛异常。原因往往是默认 UTF-8 与实际编码不一致，或错误处理策略把解码异常吞掉了。

建议把编码作为方法参数或配置项，在入口就固定下来。对确定由系统生成的 UTF-8 文件，可以使用 StandardCharsets.UTF_8；对外部上传文件，不要根据一两行内容猜编码，应该让协议、文件元数据或上游约定提供依据。无法确认时宁可拒绝并记录原因，也不要悄悄用替换字符继续导入。

文件内容在读取期间也应视为稳定输入。Oracle 对 Files.lines 的说明指出，如果在终端操作期间修改文件，结果未定义。对正在追加的日志，不要把一次扫描当成实时订阅；应采用明确的日志采集或轮转方案。对批量导入，先把文件固定下来，再开始处理更容易复现。

按任务选择 API，并防止把流式读取当成万能方案

最后按复盘清单收口：第一，确认没有在流式入口之后又调用 collect(toList()) 把全部内容收回来；第二，确认 Reader 或 Stream 被 try-with-resources 管理；第三，确认字符集来自真实契约；第四，确认单行长度、文件是否会变化以及失败后的断点策略；第五，只有在数据稳定、处理函数无共享副作用且确实有收益时，才评估并行 Stream。

Files.lines 会一次性加载全部行吗？

不会。它以 Stream 形式延迟提供行，但底层文件仍然是打开的资源，必须关闭 Stream。

已经用了 BufferedReader，还需要指定字符集吗？

需要。Reader 只负责按字符读取，字节如何解码仍由字符集决定；文件编码不明确时，先补齐输入契约。

把 Java 堆调大能解决大文件读取吗？

如果根因是 readAllLines 形成了完整列表，调大堆只能延后压力。更根本的动作是改成逐行处理，并限制业务侧缓存。

官方参考：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/file/Files.html、https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/stream/Stream.html、https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/file/Path.html。