try-with-resources的隐式finally是编译器在字节码层面自动生成的资源清理逻辑，按声明逆序调用close()，异常时作为suppressed exception附加到主异常，无需判空且自动处理多资源时序与抑制。
Java中try-with-resources的隐式finally不是手动写的finally块，而是编译器在字节码层面自动生成的资源清理逻辑。它会在try块执行结束（无论正常完成还是抛出异常）后，按声明的**逆序**自动调用每个资源的close()方法。
资源声明顺序决定关闭顺序
多个资源在try括号内用分号隔开，JVM按“后声明、先关闭”原则处理：
- 声明顺序：A → B → C
- 实际关闭顺序：C → B → A
- 这是LIFO（后进先出），确保包装流（如
BufferedInputStream）在被包装流（如FileInputStream）之前关闭
隐式finally在异常传播前执行
即使try块中抛出异常，所有资源的close()仍会执行，且发生在异常向上传播之前：
- 如果
close()也抛异常，它不会覆盖主异常，而是作为被抑制异常（suppressed exception）附加到主异常上 - 可通过
exception.getSuppressed()获取被抑制的异常 - 这避免了传统finally中
close()异常掩盖业务异常的问题
与手动finally的关键区别
隐式finally不等同于你写的finally { resource.close(); }：
立即学习“Java免费学习笔记（深入）”；
- 它由编译器生成，无需判空——只要资源变量非null且实现了
AutoCloseable，就会调用close() - 它自动处理多资源的关闭时序和异常抑制，而手动写容易漏掉null检查、重复关闭或异常覆盖
- 若资源未实现
AutoCloseable（如老版本自定义类），则无法用于try-with-resources，必须退回到手动finally
什么时候隐式finally不会运行？
极少数场景下，资源的close()可能根本不会触发：
-
System.exit()在try块中被调用，JVM立即终止，跳过所有清理 - JVM崩溃（如严重内存溢出、本地代码段错误）
- 当前线程被强制中断且未恢复，或陷入死循环/无限等待，程序无法自然退出try块
