try-with-resources 是强制性安全机制，要求资源实现 autocloseable 接口；标准库中 inputstream/outputstream、reader/writer、jdbc 4.0+ 接口、socket、zip/gzip 流、nio channel 等均支持；file/path 本身不支持，需用 files 工具类返回的资源；关闭顺序为声明逆序；close() 抛异常会被抑制并附加到主异常，需显式处理。
try-with-resources 不是“可选优化”，而是强制性安全兜底机制——只要资源用完后必须显式调用 close()，否则会泄漏（如文件句柄、数据库连接、网络套接字），就该用它。
哪些类/接口明确支持 try-with-resources？
核心判断标准只有一个：是否实现 AutoCloseable 接口（或其子接口 Closeable）。Java 标准库中以下资源类型全部符合：
-
InputStream/OutputStream及所有子类（FileInputStream、BufferedInputStream、ObjectInputStream等） -
Reader/Writer及所有子类（FileReader、BufferedWriter、PrintWriter） -
java.sql.Connection、PreparedStatement、ResultSet（JDBC 4.0+ 驱动才实现AutoCloseable） -
java.net.Socket、ServerSocket、HttpURLConnection -
java.util.zip.ZipInputStream、GZIPInputStream、DeflaterOutputStream -
java.nio.channels.Channel相关实现（FileChannel、SocketChannel）
⚠️ 注意：File 类本身不实现 AutoCloseable，不能直接放进 try (File f = ...)；Path 和 Files 工具类方法（如 Files.newInputStream()）返回的才是可关闭资源。
为什么有些 close() 方法不能自动触发？
常见误判场景：看到类有 close() 方法，就以为能用 try-with-resources。但 Java 不看方法名，只认接口契约。
立即学习“Java免费学习笔记（深入）”；
- 手动写了
public void close() { ... }，但没声明implements AutoCloseable→ 编译报错：cannot be auto-closed; it does not implement AutoCloseable - 继承了
FilterInputStream，误以为父类已实现AutoCloseable→ 实际上FilterInputStream本身不实现，只有FileInputStream等具体子类才实现 - 用了老版本 JDBC 驱动（如 MySQL Connector/J 5.1 之前），
Connection没实现AutoCloseable→ 升级驱动或手动包装 - 第三方库中的流/连接类（如某些 HTTP 客户端响应体），需查 Javadoc 或源码确认是否实现该接口
多个资源一起用时，关闭顺序怎么定？
资源按 声明顺序的逆序 关闭：最后写的先关，最先写的最后关。这对有依赖关系的资源至关重要。
try (Connection conn = DriverManager.getConnection(url);
PreparedStatement stmt = conn.prepareStatement(sql);
ResultSet rs = stmt.executeQuery()) {
// 处理结果
} // ← 关闭顺序：rs → stmt → conn如果写反了（比如把 conn 放在最后），stmt.close() 可能在 conn 已关闭后执行，部分 JDBC 驱动会抛出 SQLException 或静默失败。
- 多个资源用分号
;分隔，不能用逗号或末尾多加分号 - Java 9+ 支持复用已有变量：
FileInputStream fis = new FileInputStream("a.txt"); try (fis) { ... }，但变量不能是final且不能在 try 块内重新赋值
异常被抑制（suppressed）时，怎么不丢关键错误？
当 try 块抛出异常，且某个资源 close() 也抛异常时，后者不会覆盖主异常，而是被“抑制”并附加到主异常上。但默认不打印，容易误判为关闭成功。
try (FileInputStream fis = new FileInputStream("missing.txt")) {
throw new RuntimeException("read failed");
} catch (RuntimeException e) {
for (Throwable s : e.getSuppressed()) {
System.err.println("Suppressed: " + s);
}
}日志框架（如 Log4j、SLF4J）通常不输出 suppressed 异常，除非显式配置或调用 getSuppressed()。漏掉这步，等于关着门修水管——水漏了还不知道哪段裂了。
