Java 文件关闭失败怎么排查？try-with-resources 与 suppressed exceptions 清单

Java线上服务偶尔出现文件删不掉、连接池慢慢耗尽没法对外服务这类问题，根因大多不是业务逻辑写错，而是资源关闭的路径没覆盖到所有异常分支。对于实现了 AutoCloseable 的文件流、JDBC 连接、HTTP 响应这类资源，优先使用 try-with-resources 语法。它会在对应代码块执行结束后自动关闭所有资源，要是业务代码和资源关闭阶段同时抛出失败，你真正需要排查的关闭异常不会凭空丢掉，而是会存到 suppressed exceptions 中。

先复现一个可观察的关闭问题

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.readLine();
}

官方文档里明确说明，声明在 try-with-resources 中的资源会在语句结束时触发关闭逻辑。把文件流、Statement、ResultSet 或 HTTP 响应体放在这里管理，完全不用怕 return 提前返回、中途抛异常这类分支漏掉关闭动作。

主异常与 suppressed exception 要一起看

try (Resource r = open()) {
    runBusiness(r);
} catch (Exception e) {
    log.error("main failure", e);
    for (Throwable extra : e.getSuppressed()) {
        log.warn("close failure", extra);
    }
}

JDK 官方 Throwable 类的说明里提到，try 业务块和自动关闭动作同时抛出异常时，try 块内的异常会继续向外传播，关闭时产生的异常会被作为 suppressed 异常保存下来。如果你只看最外层的第一段堆栈，很容易误以为资源已经正常走完关闭流程。

按资源类型做检查

上线前检查清单

1. 搜索项目里手写的 finally 资源关闭逻辑，优先替换为 try-with-resources 实现。
2. 异常日志要输出完整堆栈，确保 suppressed 异常的内容也能正常打印。
3. 压测完成后观察文件句柄数、连接池活跃数和请求等待时间，确认这些指标都能正常回落。
4. 自定义资源实现 AutoCloseable 接口时，要保证 close 方法可以重复调用，同时记录必要的排查上下文。

常见问题

finally 还能用吗？

还可以用，但资源关闭场景优先选 try-with-resources；finally 更适合处理不属于 AutoCloseable 接口的自定义收尾动作。

suppressed exception 是故障主因吗？

不一定，它只代表关闭执行阶段也出现了失败。主异常仍然需要优先处理，但 suppressed 异常能解释资源为什么没有正常释放。

多个资源按什么顺序关闭？

按照声明的反序执行关闭，内层后声明的资源会先被释放。

资源泄漏类问题排查难度高，往往故障出现的时间远晚于业务代码上线的时间，很难第一时间关联上。把资源关闭的逻辑交给 try-with-resources 自动处理，再把 suppressed exception 纳入日常日志排查的固定检查项，定位这类问题的效率会高很多。