只有实现了AutoCloseable接口的资源才能用于try-with-resources，如FileInputStream、BufferedReader、Connection等；自定义类需显式实现AutoCloseable并重写close()方法。
哪些资源能用 try-with-resources 自动关闭
只有实现了 AutoCloseable 接口的类才能用于 try-with-resources。常见如 FileInputStream、BufferedReader、Connection、PreparedStatement、Scanner 等。自定义类只要重写 close() 方法并实现 AutoCloseable 就行。
注意：虽然 Closeable 是 AutoCloseable 的子接口，但 try-with-resources 只认 AutoCloseable —— 不过绝大多数 JDK 中的 Closeable 实现类（比如所有 IO 流）都同时满足条件，所以通常不用纠结。
容易踩的坑：
- 自己写的工具类如果只实现了
close()但没声明implements AutoCloseable，编译直接报错：cannot be auto-closed -
Socket、ServerSocket虽然有close()，但它们是AutoCloseable，可以放心用；而Thread或Timer就不行，强行写会编译失败
try-with-resources 的嵌套写法和异常压制机制
多个资源在同一 try 括号中声明时，会按**从左到右顺序初始化**，但按**逆序关闭**（即最后初始化的最先关闭），且每个资源的 close() 都在独立的隐式 finally 块中执行。
立即学习“Java免费学习笔记（深入）”；
如果 try 块抛出异常，而某个资源的 close() 也抛异常，后者会被“压制（suppressed）”，不会覆盖主异常，但可通过 Throwable.getSuppressed() 获取。
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
System.out.println(reader.readLine());
} catch (IOException e) {
// 主异常是 readLine() 抛的
// 如果 reader.close() 或 fis.close() 也失败，会作为 suppressed exception 存在
for (Throwable s : e.getSuppressed()) {
System.err.println("Suppressed: " + s);
}
}
关键点：
- 资源声明必须是**带初始化的局部变量**，不能是已存在的变量引用
- 不能在 try 括号里调用方法赋值（如
new BufferedReader(getStream())是合法的；但getReader()返回一个已创建对象就不行） - 所有资源的
close()调用彼此隔离，一个失败不影响另一个关闭
与传统 try-catch-finally 对比：为什么不能只靠 finally 手动关
手动在 finally 关闭资源看似可控，但容易漏掉以下细节：
- 如果 try 块和 finally 块都抛异常，finally 的异常会“吃掉” try 的异常，导致真正问题被掩盖
- 多个资源需分别判空再关，代码冗长：
if (conn != null) conn.close(); if (stmt != null) stmt.close(); ... - 若 close() 本身抛
SQLException或IOException，还要再套一层 try-catch，嵌套加深
而 try-with-resources 编译后自动展开为带异常压制逻辑的字节码，语义更安全，代码更扁平。JDK 7+ 应该默认用它，除非你明确需要控制关闭时机或顺序（比如某些资源依赖其他资源先关）。
常见错误：资源未正确关闭的典型场景
即使用了 try-with-resources，仍可能因写法不当导致资源没关：
- 把资源声明在 try 外，再传入括号：
BufferedReader r = new BufferedReader(...); try (r) { ... }→ 编译失败，必须声明在括号内 - 用 lambda 或匿名内部类持有资源引用，但资源已在 try 结束时关闭，后续调用直接
IOException: Stream closed - 数据库连接池返回的
Connection虽实现了AutoCloseable，但它的close()通常是归还连接而非真关闭——这点要结合具体连接池文档确认，别误以为“自动关=物理断开”
最隐蔽的问题是：某些框架封装的流（如 Spring 的 Resource.getInputStream()）返回的是装饰器，底层可能复用同一物理流。多次用不同 try-with-resources 包装同一个原始流，会导致第二次尝试关闭时报 Stream closed 异常。
