try-with-resources 底层统一调用 autocloseable.close()，按声明逆序关闭资源，异常会被压制并可通过 getsuppressed() 获取；close() 必须声明抛 exception，自定义实现需谨慎处理异常与资源清理。
try-with-resources 底层到底调用谁的 close()
它只认 AutoCloseable 接口，而 Closeable 是它的子接口——所以所有实现了 Closeable 的类（比如 FileInputStream、BufferedReader）都能用，但底层统一走 AutoCloseable.close() 方法。
编译器会把 try-with-resources 翻译成带 finally 块的显式调用，且按「声明顺序的逆序」插入 close() 调用。不是按变量使用顺序，也不是按资源是否为 null，而是严格看 try(…) 括号里从左到右写的顺序。
- 如果写成
try (ResourceA a = new ResourceA(); ResourceB b = new ResourceB())，则先调b.close()，再调a.close() - 哪怕
b.close()抛异常，a.close()仍会执行（JDK 7+ 支持 suppressed exception） - 若某资源构造失败（比如
new ResourceA()抛异常），它不会被 close——因为根本没声明成功
多个资源时 close() 失败会怎样
只要任意一个 close() 抛出异常，它就会成为整个 try 块最终抛出的异常；其他 close() 异常会被压制（suppressed），可通过 Throwable.getSuppressed() 拿到。
这容易误判错误根源：你以为是业务逻辑出错，其实是最后那个 close() 失败了，而真正的问题藏在 suppressed 异常里。
立即学习“Java免费学习笔记（深入）”；
- 调试时别只看主异常堆栈，记得检查
e.getSuppressed() -
close()方法本身必须声明抛Exception或其子类，否则编译不通过（AutoCloseable.close()声明抛Exception） - 如果自己实现
AutoCloseable，close()里尽量避免抛运行时异常；真要抛，建议包装成IOException这类受检异常，更符合资源管理语义
为什么 BufferedWriter 关闭后不能再写，但 close() 却可能不报错
关闭行为由具体实现决定。BufferedWriter.close() 会先 flush 缓冲区，再关闭底层 Writer；但如果底层 writer 的 close() 是空实现（比如某些测试用的 mock writer），那整个链路就“悄无声息”结束了。
这种静默关闭容易掩盖问题：比如你忘了 flush 就直接关，缓冲区数据丢了，却没任何提示。
- 不要依赖
close()自动 flush 并保证成功——关键数据建议显式调flush()后再 close - 自定义
AutoCloseable实现时，close()中的 flush、释放锁、清理线程等操作，应加 try-catch 包裹并记录日志，否则失败无迹可寻 - 注意 JDK 自带类的差异：
FileOutputStream.close()会触发系统调用，可能抛IOException；而ByteArrayOutputStream.close()是空方法，永远不抛异常
手动调用 close() 和 try-with-resources 的兼容性陷阱
如果在 try-with-resources 外又手动调了一次 close()，大概率会触发重复关闭——多数 JDK 类会检测并静默返回（如 ZipInputStream），但有些会直接抛 IOException 或进入未定义状态（比如 native 资源已被释放）。
最典型的坑是：把资源赋给字段，又在 finally 里手动 close，同时还在 try() 里声明——等于关两次。
- 资源一旦放进 try(…) 括号，就交给编译器管理，别再手动 close
- 如果资源需要跨方法复用，别用 try-with-resources，改用传统 try-finally
- 某些框架（如 Spring 的
JdbcTemplate）返回的ResultSet可能被代理，重复 close 会导致SQLException，这类情况得查文档确认生命周期
调用顺序和异常压制机制是确定的，但每个资源类对 close() 的实现自由度很高——有的立马释放句柄，有的延迟刷盘，有的甚至只是标记状态。别假设“关了就安全”，得看它实际做了什么。
