try-with-resources能自动关闭资源是因为编译器将close()插入隐式finally块，要求资源实现autocloseable接口，按声明逆序关闭，异常被压制并可通过getsuppressed()获取。
try-with-resources 为什么能自动关闭资源
它不是魔法，本质是编译器在生成字节码时，把 close() 调用“偷偷”塞进了隐式的 finally 块里。前提是资源类型必须实现 AutoCloseable 接口（Closeable 是其子接口）。没实现这个接口的类，比如普通 POJO 或老式 JDBC Connection（Java 6 及以前），直接写进去会编译报错：Cannot instantiate non-auto-closeable type。
- 必须是
AutoCloseable子类型，否则编译不通过 - 多个资源按声明顺序初始化，但按**逆序**关闭（后声明的先关），这对依赖关系很重要（比如流包装了另一个流）
- 如果
close()抛异常，且 try 块本身也抛了异常，后者是主异常，前者会被压制（suppressed），可通过getSuppressed()拿到
哪些资源支持 try-with-resources
常见且安全的包括：JDBC 的 Connection、Statement、ResultSet（Java 7+）、NIO 的 FileInputStream、BufferedReader、Files.newBufferedReader() 返回值；还有 ZipInputStream、ObjectInputStream 等。但要注意：
-
java.sql.DriverManager.getConnection()返回的Connection在 Java 7+ 已实现AutoCloseable，可直接用 -
ThreadLocal、ExecutorService、Timer不实现该接口，不能直接放进 try-with-resources —— 别硬套，否则编译失败 - 自定义资源必须显式
implements AutoCloseable，且close()方法不能抛受检异常（或只能抛Exception及其子类，但最好声明为throws Exception）
嵌套资源和异常压制的实际影响
当多个资源都关闭失败，或者 try 块中已抛异常，再触发 close() 异常时，JVM 会把关闭异常“压制”进主异常。这容易让人误以为资源没关成功却没报错——其实关失败了，只是被藏起来了。
- 调试时务必检查
e.getSuppressed()，尤其在测试资源泄漏或连接池耗尽场景 - 不要在
close()里做重试或日志打印（除非异步），它本应是幂等、轻量、快速的 - 若需精确控制关闭逻辑（如关闭前 flush、校验状态），别依赖 try-with-resources，改用手动
try-finally
try (BufferedReader r1 = Files.newBufferedReader(p1);
BufferedReader r2 = Files.newBufferedReader(p2)) {
// ...
} catch (IOException e) {
// e 是 try 块抛的异常
// r1.close() 和 r2.close() 的异常（如果有）在 e.getSuppressed() 里
}
替代方案对比：手动 finally vs try-with-resources
手动写 finally 容易漏关、顺序错、重复 close 导致 IllegalStateException；而 try-with-resources 强制声明即管理，更可靠。但它不是万能的：比如资源创建失败（构造函数抛异常），则不会进入 try 块，也不会触发任何 close() —— 这时候得靠构造逻辑自己兜底。
立即学习“Java免费学习笔记（深入）”；
- 资源在 try 小括号里实例化失败（如
new FileInputStream("missing.txt")抛FileNotFoundException），不会调用close()（因为根本没创建成功） - 如果资源需要条件初始化（比如根据 flag 决定是否 new），就无法写进 try 括号，得退回到传统方式
- Android 开发注意：minSdkVersion try-with-resources 编译后可能降级为模拟实现，某些旧设备上
close()可能不执行
close() 放在哪都不保险。 
