try-with-resources 并非万能，但必须使用：它仅适用于实现 autocloseable 的资源，能确保异常下安全关闭，避免资源泄漏；未实现该接口或需跨方法管理时，须用带判空和异常处理的 finally 块兜底。
为什么 try-with-resources 不是万能的，但必须用它
Java 7 引入的 try-with-resources 是关闭资源最安全的方式，前提是资源实现了 AutoCloseable。它自动调用 close()，哪怕发生异常也不会跳过——这是手动 finally 块容易漏掉的关键点。
常见错误现象：IOException 被吞掉、close() 根本没执行、多资源嵌套时关闭顺序混乱导致依赖失效（比如先关 BufferedReader 再关底层 FileInputStream）。
- 资源必须在
try括号内声明，且类型需实现AutoCloseable（不是Closeable的子集，但绝大多数Closeable类都同时实现了它） - 多个资源用分号隔开，关闭顺序与声明顺序相反（后声明的先关闭），这点对有依赖关系的流很重要
- 如果
close()抛异常，且已有主异常，后者会被抑制（可通过getSuppressed()获取），别指望它打断流程
示例：
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
br.readLine();
} // fis 和 br 按 br → fis 顺序关闭
自定义类实现 AutoCloseable 的三个硬约束
不是只要写了 close() 方法就“可自动关闭”——JVM 只认接口契约。自己写的工具类或封装类要支持 try-with-resources，必须严格满足以下条件：
- 必须直接或间接实现
AutoCloseable接口（不能只写个close()方法） -
close()方法签名必须是public void close() throws Exception；抛更具体的异常（如IOException）可以，但不能缩小异常范围（比如声明不抛任何异常） - 多次调用
close()必须幂等：已关闭后再次调用不能抛新异常，也不能产生副作用（比如重复释放 native 句柄）
容易踩的坑：close() 里调用 Objects.requireNonNull(this.xxx) —— 如果字段已在前序逻辑中置为 null，这里会抛 NullPointerException，破坏幂等性。
立即学习“Java免费学习笔记（深入）”；
InputStream/OutputStream 子类关闭时的隐藏行为
很多标准 I/O 类的 close() 并不只是释放文件描述符。例如 BufferedOutputStream 会在 close() 时强制刷出缓冲区；GZIPOutputStream 会写入压缩尾部数据。跳过 close() 或用错顺序，会导致数据截断或损坏。
-
FilterInputStream/FilterOutputStream子类的close()默认会调用底层流的close()，但个别实现（如旧版ZipInputStream）可能跳过，务必查 Javadoc -
Socket和ServerSocket实现了AutoCloseable，但关闭 socket 会同时关闭其getInputStream()和getOutputStream()—— 所以不要单独对它们用try-with-resources，否则可能重复关闭 - 使用
Files.newInputStream()等 NIO 工具方法返回的流，也实现了AutoCloseable，和传统 IO 流行为一致
当资源不能自动关闭时，fallback 方案怎么写才不翻车
有些场景无法用 try-with-resources：资源由外部创建、生命周期跨方法、或者类没实现 AutoCloseable（比如老版本 JDBC ResultSet 在某些驱动里没实现）。这时只能手动管理，但必须守住底线：
- 关闭逻辑必须放在
finally块里，且要判空 ——if (res != null) res.close(); - 如果
close()可能抛异常，不要让它覆盖主异常；用try-catch包住close()，并记录日志，而不是吞掉或重新抛出 - 避免在
catch块里直接调用close()：如果 try 块已抛异常，又在 catch 里触发另一个异常，原始异常就丢了
复杂点在于：多个资源需要关闭，且彼此独立（比如数据库连接和文件流），这时候每个都要独立判空 + 独立 try-catch，不能合并处理。容易被忽略的是——哪怕只是记录日志，也要确保不会因日志框架未初始化而再抛异常。
