只有实现 autocloseable 或 closeable 接口的类（如 fileinputstream、bufferedreader、jdbc 资源等）才能用于 try-with-resources；close() 在块结束时按声明逆序调用，异常会被压制，且不保证关闭成功或及时。
Java 的 try-with-resources 会自动调用资源的 close() 方法，但前提是该资源实现了 AutoCloseable 接口——不是所有“带 close 的类”都满足这个条件，也不是所有 close 调用都会如预期执行。
哪些类能放进 try-with-resources 语句里
只有声明实现 AutoCloseable（或其子接口 Closeable）的类才能用于 try-with-resources。JDK 中常见支持的包括：
-
FileInputStream、BufferedReader、Connection（JDBC）、Statement、ResultSet -
ZipInputStream、ObjectOutputStream、Scanner（构造参数为可关闭资源时） - 自定义类必须显式
implements AutoCloseable，且close()方法不能抛出受检异常（或只能抛Exception及其子类，但推荐不抛或只抛IOException）
反例：Thread、Timer、Socket（注意：它实现了 Closeable，但实际使用中需谨慎，因为 close() 可能中断读写流逻辑）。
close() 是在什么时候被调用的
try-with-resources 中的资源会在语句块结束时（无论正常退出还是因异常退出）被按**声明逆序**自动调用 close()。这和手动 finally 块中关闭的顺序相反。
立即学习“Java免费学习笔记（深入）”；
例如：
try (BufferedReader br = new BufferedReader(...);
PrintWriter pw = new PrintWriter(...)) {
// ...
}
等价于先调 pw.close()，再调 br.close()。这点对依赖顺序的资源（如嵌套流）很关键——比如 BufferedInputStream 包裹 FileInputStream，必须先关外层再关内层，否则缓冲可能丢失数据。
异常压制（suppression）机制怎么影响错误排查
如果 try 块抛出异常，且 close() 也抛异常，后者会被“压制”，仅作为 getSuppressed() 返回的异常列表存在，不会中断主异常流程。
这意味着你可能根本看不到 close() 失败的真实原因：
- 主异常是
NullPointerException，但close()实际抛了IOException→ 后者被压制 - 若想捕获所有问题，需显式检查：
e.getSuppressed()并遍历打印 - 某些框架（如 Spring JDBC）会主动吞掉
close()异常，导致连接泄漏却无日志提示
一个典型陷阱：Connection.close() 在连接已断开时可能抛 SQLException，但它常被压制，掩盖了网络或连接池配置问题。
try-with-resources 不等于绝对安全
自动调用 close() 只解决“是否调用”的问题，不解决“是否成功”或“是否及时”的问题：
- 资源未实现
AutoCloseable→ 编译失败，但有人会绕过（比如把资源声明在 try 外，再手动 close，这就失去语法保障 -
close()方法内部空实现或仅做日志 → 看似关闭，实则资源（如文件句柄、数据库连接）仍在占用 - 资源被提前
null或重新赋值 → 编译器仍会尝试调用 close，但对象可能已不可达，引发NullPointerException - 多线程共享同一资源实例 →
try-with-resources关闭后其他线程继续使用，抛IllegalStateException或静默失败
最易被忽略的一点：流式 API 链式调用（如 Files.newBufferedReader(Paths.get("x")).lines().forEach(...)）中，BufferedReader 没有被显式绑定到 try 资源列表，也就不会自动关闭——必须拆成独立声明。
