try-with-resources要求资源必须实现AutoCloseable接口，否则编译报错；多资源按逆序关闭，close()异常被抑制，装饰器只需声明最外层流。
try-with-resources 语法要求资源必须实现 AutoCloseable
Java 7 引入的 try-with-resources 只接受实现了 AutoCloseable 接口的对象（包括 Closeable，因为后者是前者的子接口）。如果你传入一个普通对象或未实现该接口的类，编译器会直接报错：cannot be auto-closed; it does not implement java.lang.AutoCloseable。
常见踩坑点：
- 自定义流类只重写了
close()方法但没声明implements AutoCloseable—— 不够，必须显式实现接口 - 使用了第三方库中的流类型，但版本过低（如某些老版 Apache Commons IO 类），未适配 Java 7+ 的
AutoCloseable - 试图在
try括号里放多个资源时，用逗号分隔但其中某个资源为null—— 这不会导致 NPE，但该资源不会被关闭；建议提前校验或用Objects.requireNonNull()
多资源声明时关闭顺序是「逆序」且独立
资源按声明顺序从左到右初始化，但关闭时严格按相反顺序执行，且每个资源的 close() 都会被调用，无论前面是否已抛异常。
例如：
try (FileInputStream fis = new FileInputStream("a.txt");
FileOutputStream fos = new FileOutputStream("b.txt")) {
// ...
}
fos.close() 先于 fis.close() 调用。这个顺序对资源依赖关系很重要——比如你用 BufferedWriter 包裹 FileWriter，必须让外层先关，否则内层可能丢数据。
注意：
- 即使
fos.close()抛出异常，fis.close()仍会执行 - 如果多个
close()都抛异常，只有第一个被抛出，其余会作为 suppressed exception 附加到主异常上（可通过getSuppressed()获取）
try-with-resources 中的异常处理逻辑比普通 try 更复杂
当 try 块本身抛异常，且资源 close() 也抛异常时，主异常优先抛出，close() 异常被抑制。这意味着你不能靠捕获主异常来感知所有失败点。
调试建议：
- 在开发阶段，可临时加日志到
close()方法里，确认是否真被调用 - 若需确保某资源一定完成清理（比如释放锁、回滚事务），不要完全依赖
AutoCloseable，而应在finally或单独方法中再兜底 - 避免在
close()中做耗时或可能阻塞的操作——它本应是轻量的，否则会拖慢整个try块退出
InputStream/OutputStream 子类基本都支持，但要注意装饰器链的写法
像 BufferedInputStream、ObjectOutputStream、GZIPOutputStream 等都实现了 AutoCloseable，可以直接用。但关键在于：**只声明最外层流即可**，内层会随外层 close() 自动级联关闭。
错误写法（重复声明、冗余且易出错）：
try (FileInputStream fis = new FileInputStream("in.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) { ... }
正确写法（只声明装饰后顶层）：
try (BufferedInputStream bis = new BufferedInputStream(
new FileInputStream("in.txt"))) { ... }
原因：
-
BufferedInputStream.close()内部会调用底层in.close() - 重复声明可能导致同一底层流被多次关闭（虽然多数实现幂等，但非强制保证）
- 代码更简洁，语义更清晰：你关心的是“这个缓冲输入流”，不是它的构造细节
真正容易被忽略的是：有些自定义装饰器忘了在 close() 里调用 super.close() 或底层 close()，结果造成资源泄漏——这种 bug 在 try-with-resources 下反而更隐蔽，因为看起来“语法没错”。
