历史：在 Java 7 之前，资源管理依赖于冗长的 try-catch-finally 构造，开发人员在 finally 块中手动调用 close()。这种模式错误率高，尤其是在处理多个资源或清理期间抛出的异常时。Java 7 通过 Project Coin 引入了 try-with-resources 语句，编译器将其转换为复杂的字节码，自动关闭资源，同时保持异常链的完整性。
问题：当多个资源实现 AutoCloseable 时，JVM 必须确保按照反向初始化顺序关闭，以尊重依赖关系层次。例如，包装文件流的输出流必须优先关闭以刷新缓冲区。此外，如果 try 块和 close() 方法都抛出异常，规范要求将块中的主要异常传播，而清理异常通过 Throwable.addSuppressed() 附加为抑制异常。这要求编译器生成合成的 try-catch 块来围绕每个资源的关闭，并管理临时变量来保存异常。
解决方案：编译器将 try-with-resources 分解成一个包含原始逻辑的主 try 块，后跟一系列嵌套的 finally 块——每个资源一个——按 LIFO 顺序关闭资源。对于每个资源，编译器生成捕获 Throwable 的字节码，将其存储在合成变量中，调用 close()，如果 close() 抛出，则在捕获的异常上调用 addSuppressed() ，然后重新抛出。在 Java 9 及以上版本中，编译器还有效地处理最终资源，通过将它们包装在临时合成变量中，以确保在生成的清理块中可访问。
// 源代码 public String readFirstLine(String path) throws IOException { try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } } // 概念字节码转换 public String readFirstLine(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); Throwable primaryException = null; try { return br.readLine(); } catch (Throwable t) { primaryException = t; throw t; } finally { if (br != null) { if (primaryException != null) { try { br.close(); } catch (Throwable suppressed) { primaryException.addSuppressed(suppressed); } } else { br.close(); } } } }
我们遇到过一个生产事件，在高负荷下，遗留库存服务间歇性出现数据库连接泄漏。代码库使用手动 try-catch-finally 构造，开发人员在 finally 块中调用 close()，但这些实现缺乏对清理操作本身的适当异常处理。当 close() 抛出异常时，来自业务逻辑的原始 SQLException 丢失，掩盖了根本原因，并阻止了正确的连接池返回。
考虑的第一个补救策略涉及通过严格的代码审查和静态分析工具（如 SonarQube）强化手动清理模式。这种方法要求开发人员在每个 close() 调用中编写防御性代码，将其包装在嵌套的 try-catch 块中，以抑制次级异常，但在快速开发周期中仍然容易出错，并增加了显著的样板代码，复杂化了可读性。我们最终拒绝了这个方案，因为人类的监督无法确保在不断增长的代码库中一致应用。
评估的第二个策略是 Guava's Closer 工具，它提供了一个流畅的 API 来注册资源并自动管理关闭顺序。虽然 Closer 正确处理异常抑制和反向清理，但它向试图尽量减少其足迹的微服务引入了一个庞大的外部依赖，并且需要重构异常类型以适应 Closer 的特定运行时异常包装。由于依赖权重和其强加的非标准异常处理模式，我们决定不采用此方案。
第三种方法将所有资源处理迁移到标准的 try-with-resources 语句，利用编译器生成的字节码来自动清理。这个解决方案消除了手动样板，保证了通过合成字节码块按 LIFO 的顺序关闭，并通过 Throwable.addSuppressed() 自动保留异常层次，而无需库依赖。我们选择了这种方法，因为它在编译器级别解决了根本原因，将代码复杂性减少了大约三百行，并符合现代 Java 的最佳实践。
迁移后，生产监控中的连接泄漏降至零，调试效率显著提高，因为工程师现在能够看到原始的 SQLException，并附加清理失败的抑制跟踪。该服务实现了零停机时间的部署兼容性，因为字节码级的保证在不同的 JVM 版本中始终有效，无需运行时配置更改。
当 try 块正常完成时，try-with-resources 如何处理 close() 方法抛出的异常？
当 try 块执行而不抛出时，编译器生成的 finally 块针对每个资源调用 close()。如果 close() 抛出异常，该异常成为传播到调用者的主要异常，因为没有先前的异常可以抑制。JVM 不会包装或丢弃此异常；它将按原样传播，可能会中断链中的后续资源关闭。理解这一区别至关重要，因为它解释了资源实现必须确保 close() 保持幂等且最低侵入性的原因，因为失败的 close() 会掩盖业务逻辑的成功完成。
为什么资源必须按反向初始化顺序关闭，以及什么字节码机制执行此操作？
资源往往表现出封装依赖性，其中外部包装器（如 BufferedWriter）持有对底层流（如 FileOutputStream）的引用。首先关闭底层流会使包装器处于不一致的状态，可能丢失缓冲数据或在包装器尝试刷新时导致 IOException。编译器通过生成嵌套的 finally 块来强制反向顺序关闭（LIFO），其中最内层的 finally（对应最后声明的资源）在外部 finally 块之前执行。这个结构确保 BufferedWriter.close() 在 FileOutputStream.close() 释放文件句柄之前将其缓冲区刷新到底层流，防止数据丢失和资源损坏。
在字节码生成方面，Java 7 和 Java 9 之间关于资源声明范围有什么变化？
Java 7 要求在 try 头中声明的资源变量必须显式为 final，在资源需要重新分配或来自复杂表达式时限制灵活性。Java 9 放宽了这一限制，允许在 try 头外部声明有效最终资源，但编译器仍然生成合成变量以保留生成的清理块内的引用。具体来说，如果一个资源被赋值给 r 变量（在 try-with-resources 之外），编译器生成的字节码如下：final AutoCloseable resource$1 = r; 以确保引用在清理时保持稳定，即使原始变量 r 在范围内后续被修改（尽管这种修改将违反有效最终状态）。这种合成变量注入确保清理代码始终引用原始对象实例，防止空指针异常或在 finally 块执行期间的过时引用。