Java try-with-resources 资源关闭实战：文件流和目录扫描这样写更稳

Java 里很多对象都不是“用完就自然消失”的普通对象，比如文件流、目录扫描流、压缩包流、网络输入流。它们背后通常占着文件句柄或系统资源，如果忘记关闭，短时间内可能看不出问题，流量一上来就容易出现文件无法删除、句柄数升高、任务卡住等现象。

try-with-resources 是 Java 7 之后非常实用的一种写法。它把“声明资源”和“关闭资源”放在同一个语法边界里，只要对象实现了 AutoCloseable，离开代码块时就会自动调用 close()。本文用文件读取和目录扫描两个场景，把它讲清楚。

摘要

资源关闭最怕两类问题：一是 finally 分支太多，某个路径漏关；二是多个资源互相依赖，关闭顺序写反。try-with-resources 的核心价值是把关闭动作交给语法保证：声明在括号里的资源会在代码块结束后自动关闭，并且按照声明顺序的反向依次关闭。

适合人群

适合正在写 Java 文件处理、批量导入、日志解析、压缩包读取、简单 I/O 工具类的开发者。你需要了解基本 Java 语法、异常处理和 close() 的含义。

目录

• 为什么手动关闭容易出问题
• 用 try-with-resources 读取文件
• 多个资源的关闭顺序
• 异常被覆盖时怎么排查
• 上线前检查清单

一、为什么手动关闭容易出问题

传统写法通常会在 finally 里关闭资源。单个资源时还能接受，一旦有多个资源、多个提前返回路径、多个异常分支，代码就会变得很绕。

BufferedReader reader = null;
try {
    reader = Files.newBufferedReader(path, StandardCharsets.UTF_8);
    String firstLine = reader.readLine();
    return firstLine == null ? "" : firstLine.trim();
} finally {
    if (reader != null) {
        reader.close();
    }
}

这段代码不算错，但它把“业务读取”和“资源收尾”混在一起了。后续如果再加一个输入流、一个包装流，或者在 finally 里加日志，漏掉某个分支的概率就会变高。

二、用 try-with-resources 读取文件

更推荐把资源直接声明在 try 后面的括号里。代码块结束时，不管正常返回还是抛出异常，资源都会被关闭。

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

public class FileReadDemo {
    public static String readFirstLine(Path path) throws IOException {
        try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
            String firstLine = reader.readLine();
            return firstLine == null ? "" : firstLine.trim();
        }
    }
}

这张图对应的逻辑很简单：打开文件，读取数据，离开代码块时自动关闭，最后把稳定结果返回。业务代码只关心读取逻辑，资源生命周期由语法边界兜住。

三、多个资源的关闭顺序

try-with-resources 可以同时声明多个资源。需要注意：关闭顺序是声明顺序的反向。先声明的资源最后关闭，后声明的资源先关闭，这通常符合包装流的依赖关系。

try (
    InputStream input = Files.newInputStream(path);
    BufferedInputStream buffer = new BufferedInputStream(input)
) {
    byte[] chunk = buffer.readNBytes(1024);
    System.out.println("读取字节数：" + chunk.length);
}

上面代码里，buffer 依赖 input。代码块结束后会先关闭 buffer，再关闭 input。如果手动写 finally，这个顺序就要自己维护，而且每新增一个资源都要同步修改收尾逻辑。

左侧是手动关闭常见风险：分支多、少关一步，问题会慢慢累积。右侧是 try-with-resources 的优势：资源声明集中，关闭顺序可预期，异常信息也更容易保留。

四、目录扫描也要记得关闭

很多人会记得关闭文件流，却忽略 Files.list()、Files.walk() 返回的 Stream 也需要关闭。它们可能持有目录句柄，尤其是批量扫描时更应该放进 try-with-resources。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;
import java.util.stream.Stream;

public class DirectoryScanDemo {
    public static List listLogFiles(Path dir) throws IOException {
        try (Stream paths = Files.list(dir)) {
            return paths
                .filter(path -> path.getFileName().toString().endsWith(".log"))
                .sorted()
                .toList();
        }
    }
}

这类代码的坑在于：Stream 看起来像普通集合管道，但底层可能还连着目录资源。放进 try 括号后，扫描结束就会收尾，避免批处理任务长时间占用目录句柄。

五、异常被覆盖时怎么排查

资源关闭本身也可能失败。try-with-resources 会保留主异常，并把关闭时产生的异常放到 getSuppressed() 里。排查线上问题时，不要只看主异常消息，也可以把被抑制的异常打印出来。

try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
    return reader.readLine();
} catch (IOException error) {
    for (Throwable hidden : error.getSuppressed()) {
        System.err.println("关闭资源时的附加异常：" + hidden.getMessage());
    }
    throw error;
}

这个细节对定位问题很有帮助。比如主异常来自读取失败，而附加异常来自关闭失败，两者一起看，才能判断是数据问题、磁盘问题，还是底层资源状态异常。

常见问题

1. 哪些对象可以放进 try-with-resources？

只要实现了 AutoCloseable 或 Closeable，就可以放进去。常见对象包括输入输出流、Reader、Writer、ZipInputStream、Scanner、目录扫描返回的 Stream 等。

2. 资源声明在外面还能用吗？

Java 9 之后，如果变量是 effectively final，也可以在 try 括号里引用已有资源。不过日常业务里，更推荐在括号内声明资源，边界更清楚。

3. close 方法还需要手动调用吗？

放进 try-with-resources 后通常不需要手动调用。重复关闭有时不会出错，但会让代码语义变乱，后续维护者也会困惑。

上线前检查清单

• 文件流、目录扫描流、压缩流是否都放进了 try-with-resources。
• 多个资源是否按依赖关系声明，确认关闭顺序符合预期。
• 是否避免在 finally 里堆太多收尾分支。
• 异常日志是否保留主异常和 getSuppressed() 信息。
• 批量任务是否在循环内及时释放每次打开的资源。

总结

try-with-resources 不是语法糖那么简单，它是在帮代码建立资源生命周期边界。文件读取、目录扫描、压缩包处理这类场景，只要资源实现了关闭接口，就优先把它放进 try 括号里。这样业务逻辑更清爽，关闭顺序更稳定，异常信息也更完整。