只有实现 AutoCloseable 接口的类才能用于 try-with-resources，如 FileInputStream、BufferedReader、JDBC 4.0+ 的 Statement 等；自定义类需实现该接口并提供 public void close() throws Exception 方法。
哪些类能用 try-with-resources？看它是否实现 AutoCloseable
只有实现了 AutoCloseable 接口的类，才能直接用于 try-with-resources 语句。Java 标准库中绝大多数 I/O 类都实现了它，但不是所有“带 close() 方法”的类都自动合规——比如老版本的 java.sql.Connection（JDBC 4.0+ 才实现 AutoCloseable）。
判断方法很简单：查 Javadoc，确认该类或其父类是否声明 implements AutoCloseable；或者在 IDE 里按住 Ctrl 点击类名，跳转到定义处验证。
-
FileInputStream、BufferedReader、ObjectOutputStream✅ -
ZipInputStream、Scanner（构造参数为可关闭资源时）✅ -
java.sql.Statement、ResultSet（JDBC 4.0+）✅ -
java.util.Scanner（包装了System.in）⚠️ 虽然可关闭，但关闭后会连带关闭System.in，一般不推荐 -
java.io.FileInputStream的子类若重写了close()却没声明异常类型为Exception（必须是Exception或其子类），则可能编译失败 ❌
自定义类怎么支持 try-with-resources？必须实现 close() 且抛 Exception
自己写的资源类，只要满足两个条件就能进 try-with-resources：
- 声明
implements AutoCloseable - 提供一个 public 的
void close() throws Exception方法（不能是throws IOException单独限定，除非IOException是唯一受检异常且父类没扩大范围）
注意：如果 close() 方法抛出的是非受检异常（如 RuntimeException），编译器不强制要求处理，但仍会被 try-with-resources 捕获并压制（suppressed），需通过 Throwable.getSuppressed() 查看。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
public class MyResource implements AutoCloseable {
@Override
public void close() throws Exception {
System.out.println("cleaning up...");
// 可能抛 IOException / SQLException / 自定义受检异常
}
}
常见误用：嵌套流、重复关闭、未捕获异常链
多个资源嵌套时（比如 BufferedInputStream 包着 FileInputStream），只需声明最外层——try-with-resources 会按声明逆序调用 close()，内层资源通常已在外层 close() 中被关闭。显式再关一次会触发 IOException（如 “Stream closed”）。
- ❌ 错误写法：
try (FileInputStream fis = new FileInputStream("a.txt"); BufferedInputStream bis = new BufferedInputStream(fis)) { bis.read(); } finally { fis.close(); // 重复关闭！运行时报错 } - ✅ 正确写法：只让 try-with-resources 管理，不手动 close
- ⚠️ 异常压制风险：如果 try 块抛异常，且
close()也抛异常，后者会被压制。调试时容易漏掉真正的问题根源 - ? 查压制异常：
catch (IOException e) { for (Throwable suppressed : e.getSuppressed()) { System.err.println("Suppressed: " + suppressed); } }
性能与兼容性提醒：别为“语法糖”牺牲可读性或控制力
try-with-resources 编译后本质是 try-catch-finally + 显式 close 调用，没有额外运行时开销。但它强制资源生命周期绑定语句块作用域，不适合以下场景：
- 需要跨方法传递资源（如把
Connection传给 DAO 层再关）→ 改用传统 try-finally - close() 逻辑复杂，需根据状态决定是否关闭 → 不适合硬塞进 auto-close 流程
- Android 低版本（API
资源释放的可靠性，不取决于语法是否简洁，而在于 close() 是否真被调用、是否处理了异常链、是否和业务生命周期对齐。语法糖只是工具，不是银弹。
