Java Files.lines 读取大文件怎么避免句柄泄漏：Stream 关闭与异常路径验收

日志导入任务跑了几个小时后，机器上的打开文件数慢慢上涨，代码里却没有显眼的 FileInputStream。顺着调用链看，问题常常藏在 Files.lines(path)：它返回的是一个惰性读取的 Stream，同时占用文件资源，不能把它当成普通集合用完就算。

Files.lines 为什么会让文件资源留到方法外

Files.lines(path) 不会一次性把整文件装进内存，而是按需产生行。这个特性很适合处理几十 GB 的访问日志，但它也意味着资源生命周期跟着 Stream 走：Stream 没有关闭，底层读取器就可能继续占用文件描述符。

下面这段代码看起来简洁，实际把关闭责任丢掉了：

long errors = Files.lines(logPath)
        .filter(line -> line.contains("ERROR"))
        .count();

短文件测试往往不会立刻暴露问题，持续执行的 worker 才会把这个缺口放大。尤其是把读取逻辑封装成工具方法、每轮处理不同文件时，句柄增长会比堆内存异常更早出现。

最小修复：让 Stream 覆盖完整处理过程

把 Stream 声明在 try-with-resources 的资源列表中，创建、消费和关闭都放在同一个作用域里：

try (Stream lines = Files.lines(logPath, StandardCharsets.UTF_8)) {
    long errors = lines
            .filter(line -> line.contains("ERROR"))
            .count();
    System.out.println("error lines=" + errors);
}

这里的关键不是 count()，而是 lines 作为资源被声明。正常返回、过滤器抛异常、计数操作提前结束时，Java 都会执行关闭动作；如果关闭本身也出错，异常会按 try-with-resources 的规则作为 suppressed exception 保留下来。

惰性读取和关闭时机要分开判断

中间操作例如 filter、map 只是在组装处理链，通常不会马上读取文件。终止操作如 count、findFirst、forEach 才会推动数据读取，但它们不会替你把 Stream 带出资源作用域。

有短路操作时也一样：

try (Stream lines = Files.lines(logPath)) {
    Optional first = lines
            .filter(line -> line.startsWith("request_id="))
            .findFirst();
    first.ifPresent(System.out::println);
}

findFirst 找到结果后可以少读几行，但文件资源仍由 try 块负责释放。不要因为“已经找到结果”就提前把 Stream 放到外层缓存，那个做法会让生命周期变得不可见。

异常路径怎么验收才算真的修好

测试不能只覆盖正常文件。可以在消费过程中主动抛出一个受控异常，确认异常离开 try 块后资源仍然关闭：

try (Stream lines = Files.lines(logPath)) {
    lines.forEach(line -> {
        if (line.length() > 4096) {
            throw new IllegalArgumentException("line too long");
        }
    });
} catch (IllegalArgumentException ex) {
    System.err.println(ex.getMessage());
}

生产验收至少观察三件事：任务是否还能返回预期错误、重复跑多轮后打开文件数是否回到基线、异常对象的 suppressed 列表是否保留关闭阶段的信息。只测第一项，容易把资源泄漏误判成“功能没问题”。

常见写法误区与边界

只把 Path 放进 try 块够不够

不够。Path 只是路径值，不是打开的资源；应当把 Files.lines 返回的 Stream 放进资源列表。

把 Stream 收集成 List 后还能关闭吗

可以，但收集动作仍要在 try 块内完成。收集完成后再离开作用域，文件资源才有明确的关闭点。

用 parallel 处理能解决句柄问题吗

不能。并行只改变处理方式，不改变资源所有权；如果每个任务都打开 Stream，仍然必须让每个 Stream 在自己的作用域内关闭。

一份可落地的检查清单

• 搜索所有 Files.lines 调用，确认返回值没有被丢弃或跨方法长期保存。
• 检查 Stream 是否出现在 try-with-resources 的资源列表中。
• 分别覆盖正常结束、短路结束、读取异常和业务处理异常。
• 在循环任务中记录打开文件数，比较修复前后的稳定基线。

相关问题

Files.readAllLines 和 Files.lines 怎么选

文件较小且需要随机访问时可以考虑 readAllLines；大文件或只需顺序处理时，Files.lines 更省内存，但必须显式管理 Stream 生命周期。

Stream.close 会关闭底层文件吗

对 Files.lines 返回的 Stream，关闭操作会释放其关联的文件读取资源。把关闭动作交给 try-with-resources 更不容易漏掉异常路径。

为什么本地测试看不出泄漏

短任务、文件描述符上限较高或垃圾回收及时，都可能掩盖问题。用多轮文件处理和打开文件数监控，才能让资源生命周期变成可观察结果。

小结

Files.lines 的优势是惰性读取，风险是资源不会因为终止操作自动变成“无主”。把 Stream 放进 try-with-resources，并用正常、短路和异常三类路径验收，才能同时得到正确结果和可控的文件句柄数量。