必须用 try-with-resources 管理的资源包括文件流、数据库连接、网络套接字、ZIP/GZIP 输入流等所有实现 AutoCloseable 接口且需显式关闭的资源，它们会在 try 结束时逆序自动调用 close()，并妥善处理 suppressed 异常。
哪些资源必须用 try-with-resources 管理
Java 中 try-with-resources 不是“可选优化”，而是针对实现了 AutoCloseable 接口的资源的**强制性安全兜底机制**。只要资源在使用后必须显式调用 close()（否则会泄漏），就该用它——比如文件流、数据库连接、网络套接字、ZIP 文件句柄等。
典型误用是只对 FileInputStream 用，却漏掉包装它的 BufferedInputStream 或 ObjectInputStream。实际上，只要声明在 try (…) 括号里的资源，都会按**逆序自动调用 close()**，哪怕中间抛出异常。
-
FileInputStream、FileOutputStream -
Connection、Statement、ResultSet（JDBC 4.1+） -
Socket、ServerSocket、HttpURLConnection -
ZipInputStream、GZIPInputStream
try-with-resources 与手动 close 的关键差异
手动 finally 块里 close() 最大问题是：如果 try 块已抛异常，close() 再抛异常就会被吞掉（除非你层层 catch 并 addSuppressed）。而 try-with-resources 会把 close() 异常作为 suppressed exception 附加到主异常上，不丢失上下文。
另一个易忽略点：资源变量必须是 final 或 effectively final，不能在 try 块内重新赋值；否则编译报错 variable is not effectively final。
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) {
// 正确：bis 依赖 fis，且都自动关闭
bis.read();
} catch (IOException e) {
// e.getSuppressed() 可能包含 fis.close() 或 bis.close() 的异常
}
嵌套资源或动态获取资源怎么处理
如果资源不是构造时就能拿到（比如从池中借、或根据条件创建），就不能直接写在 try 括号里。这时得先声明为 null，再在 try 块内初始化，但必须确保所有分支都完成初始化，否则可能触发 NullPointerException 在 close() 阶段。
更稳妥的做法是封装成工具方法，或改用 try-finally（仅限极少数无法改造的场景）。但绝大多数情况下，应重构逻辑，让资源创建集中在括号内。
- 错误写法：
InputStream is = null; if (cond) is = new FileInputStream(...); try (is) { ... }→ 编译失败 - 正确写法：用三元运算符或提取方法保证单点创建，例如
try (InputStream is = openStream()) { ... } - 注意：自定义资源类必须正确实现
close()，尤其要容忍多次调用（幂等）
性能和兼容性要注意什么
try-with-resources 是 Java 7 引入的语法糖，底层仍生成 finally 块，无 runtime 性能损耗。但需留意：Android minSdkVersion
另一个坑是资源关闭顺序：多个资源用分号隔开时，关闭顺序与声明顺序相反。这在有依赖关系时很关键——比如 BufferedWriter 必须在 FileWriter 之前关闭，否则缓冲区内容可能丢失。所以声明顺序应是“外层→内层”：
try (FileWriter fw = new FileWriter("out.txt");
BufferedWriter bw = new BufferedWriter(fw)) { // bw 在 fw 之后声明
bw.write("hello");
} // 关闭顺序：bw.close() → fw.close()
关不掉的资源（比如某些 NIO Channel 在未读完时调用 close() 会中断操作），得结合业务逻辑判断是否真能在此刻关闭——语法再规范，也救不了语义错误的设计。
