try-with-resources 关闭顺序会如何影响主异常

结论很明确：try-with-resources 会按资源初始化顺序的反序调用 close()。如果 try 主体已经抛出异常，它就是主异常，后续关闭异常会按实际发生顺序加入它的 suppressed 列表；如果主体正常结束，那么反向关闭时第一个抛出的异常成为主异常，后续关闭异常被它抑制。

所以，资源声明顺序不仅决定谁先释放，也会在多个 close() 同时失败时决定哪个异常站在最外层。排查这类问题不能只打印 getMessage()，还要读取 getSuppressed()。

Java 语言规范：https://docs.oracle.com/javase/specs/jls/se25/html/jls-14.html#jls-14.20.3

我为什么会把“关闭失败”误判成业务失败

我遇到过一次批量导出失败：日志最上面是写入阶段的异常，看起来像业务数据问题，但真正阻止临时文件落盘的是后面两个资源的关闭失败。最初的日志只记录了主异常消息，没有把 suppressed 异常展开，结果定位方向完全偏了。

后来把资源声明、反向关闭和异常归并拆开看，规则其实并不复杂。关键是先判断“在开始关闭资源之前，是否已经存在一个异常”，再判断反向关闭中还有哪些异常出现。

先建立一张完整判断表

Java 语言规范还规定，一个资源关闭失败不会阻止其他资源继续关闭。也就是说，即使 second.close() 抛异常，first.close() 仍会被调用；异常归并机制正是为了不丢失这些并列失败。

声明在后面的资源为什么先关闭

多个资源在资源头中从左到右初始化，却从右到左关闭。下面的 second 后创建，因此先调用 second.close()，再调用 first.close()：

public final class CloseOrderDemo {
    static final class DemoResource implements AutoCloseable {
        private final String name;
        private final boolean failOnClose;

        DemoResource(String name, boolean failOnClose) {
            this.name = name;
            this.failOnClose = failOnClose;
        }

        @Override
        public void close() throws Exception {
            // 真实资源应先释放底层句柄，再报告关闭失败
            if (failOnClose) {
                throw new Exception("close failed: " + name);
            }
        }
    }

    public static void main(String[] args) {
        try (var first = new DemoResource("first", true);
             var second = new DemoResource("second", true)) {
            // 主体先失败，用来观察关闭异常如何进入 suppressed 列表
            throw new IllegalStateException("body failed");
        } catch (Exception main) {
            // main 是最终向外传播或被当前 catch 捕获的主异常
            System.err.println("main: " + main.getMessage());

            // 不能只记录主异常，关闭阶段的并列失败在这里
            for (Throwable suppressed : main.getSuppressed()) {
                System.err.println("suppressed: " + suppressed.getMessage());
            }
        }
    }
}

这个结构中，主体的 IllegalStateException 保持为主异常。随后 second.close() 的异常先加入 suppressed 列表，first.close() 的异常后加入。声明顺序改变后，关闭顺序和两个 suppressed 异常的顺序也会随之改变。

从工程关系看，这种反序很适合“底层资源先创建、外层包装器后创建”的结构。例如先声明文件流，再声明缓冲流，缓冲流会先完成自身收尾，然后底层流再关闭。资源头的顺序应表达真实依赖，而不是按变量名随意排列。

try 主体已经抛异常时，关闭失败放在哪里

当主体异常已经存在，Java 不会用关闭异常覆盖它。这样能保留最早导致控制流异常退出的原因，同时把关闭阶段的失败附加到主异常上。Throwable.printStackTrace() 会打印 suppressed 条目，但很多结构化日志只取类型和消息，因此仍建议显式采集。

这里的“抑制”不是忽略。关闭异常依然保存在主异常对象中，可以通过 getSuppressed() 读取。它与 getCause() 的语义不同：cause 表示一个异常导致另一个异常，suppressed 表示多个相邻阶段都失败，但最终只能有一个异常向外传播。

try 主体正常结束时，哪个 close 异常成为主异常

如果主体没有异常，反向关闭阶段就还没有“既存主异常”。此时最先发生的关闭异常会成为主异常。对 first; second 的声明顺序来说，second.close() 先执行，所以它的异常成为主异常；之后 first.close() 的异常进入前者的 suppressed 列表。

static void closeOnlyFailure() {
    try (var first = new CloseOrderDemo.DemoResource("first", true);
         var second = new CloseOrderDemo.DemoResource("second", true)) {
        // 主体正常结束，让关闭阶段决定主异常
        System.out.println("work completed");
    } catch (Exception main) {
        // second 后声明、先关闭，因此它的关闭异常成为 main
        System.err.println("main: " + main.getMessage());

        // first 的关闭异常仍会保留，不会阻止 first.close() 被调用
        for (Throwable suppressed : main.getSuppressed()) {
            System.err.println("suppressed: " + suppressed.getMessage());
        }
    }
}

这也是标题中“关闭顺序影响主异常”的核心：只有在关闭前没有更早异常时，第一个关闭失败才会升级为主异常。主体已经失败时，声明顺序只会改变 suppressed 异常的排列；主体正常时，声明顺序还可能改变最终捕获到的异常类型和消息。

资源初始化到一半失败又会怎样

资源初始化从左到右进行。如果 first 成功，而 second 的构造或工厂方法抛出异常，try 主体不会执行，后面的资源也不会初始化。已经成功获得的 first 仍会被自动关闭。

此时 second 的初始化异常是主异常；若 first.close() 也失败，它会被加入初始化异常的 suppressed 列表。这个边界很重要，因为一些连接池、压缩流或事务资源可能在“进入主体之前”就失败，日志不能假设异常一定来自主体。

我现在采用的诊断流程

1. 画清依赖：底层资源写在前，依赖它的包装资源写在后，让包装层先关闭。
2. 区分阶段：记录失败来自初始化、try 主体还是 close()，不要只按异常类型猜。
3. 保留完整 Throwable：日志框架传入异常对象，不要只拼接 getMessage()。
4. 展开 suppressed：对数据库连接、文件落盘、压缩完成和事务结束等关键资源单独记录资源类型与 suppressed 异常。
5. 检查 catch 位置：try-with-resources 后面的 catch 和 finally 都在资源关闭完成后运行，因此 catch 看到的是归并后的最终异常。
6. 验证 close 契约：自定义 AutoCloseable 应尽量先释放资源、标记为关闭，再抛出关闭异常。

Oracle 的 AutoCloseable API 还提醒，实现方应尽量抛更具体的异常类型，避免从 close() 抛 InterruptedException，并尽可能让关闭操作具备幂等性。需要注意的是，AutoCloseable.close() 本身并不保证多次调用一定无副作用，所以不要因为某个 Closeable 实现可重复关闭，就假定所有自定义资源都可以。

几个常见误区

把最重要的资源写在最后，它就会最后关闭吗？

恰好相反。最后声明的资源最先关闭。顺序应依据包装和依赖关系决定，而不是“重要程度”。

只要用了 try-with-resources，就不会丢异常吗？

异常对象本身通常会保留 suppressed 信息，但日志代码如果只记录消息，仍然会把它丢掉。传递完整异常对象，必要时遍历 getSuppressed()。

第一个声明的资源关闭失败，会阻止其他资源关闭吗？

不会。因为它本来就是最后关闭的资源；更一般地说，一个资源关闭异常不会阻止剩余资源继续关闭。

手写 finally 和 try-with-resources 的主异常规则一样吗？

不一定。手写 finally 若直接抛出关闭异常，可能覆盖主体异常；try-with-resources 的翻译规则会保留既有主异常，并调用 addSuppressed() 记录关闭失败。

关闭顺序与异常归并速查表

总结

判断 try-with-resources 的主异常，可以记住两个问题：关闭前是否已经有异常，反向关闭中谁先失败。前者决定主体或初始化异常是否继续当主异常，后者决定没有既存异常时哪个关闭异常被提升。

声明顺序应表达资源依赖，日志应保留完整异常对象并读取 suppressed 列表。这样既能让资源可靠释放，也不会把真正的业务失败、初始化失败或关闭失败混成一条模糊日志。