try-with-resources要求资源必须实现AutoCloseable接口，关闭按声明逆序执行，异常会被抑制需主动检查，且不能替代finally中的业务清理逻辑。
try-with-resources 必须实现 AutoCloseable 接口
Java 的 try-with-resources 语法只接受实现了 AutoCloseable 接口的资源，不是所有带 close() 方法的类都自动兼容。比如老版本的 java.sql.Connection（JDBC 4.0+）才实现该接口；若用的是旧驱动或自定义类，必须显式声明 implements AutoCloseable，否则编译报错：cannot be auto-closed; it does not implement AutoCloseable。
常见误用场景：
- 手动写了
public void close() { ... }，但没加implements AutoCloseable - 继承了某个父类（如
FilterInputStream），以为它已实现，结果发现父类本身不实现（实际是子类如FileInputStream才实现） - 使用第三方库中的流/连接类，文档未明确标注是否支持，需查源码或 Javadoc 确认
多个资源声明时注意关闭顺序
资源按声明顺序从左到右初始化，但关闭时**逆序执行**——最后声明的最先关闭。这点在有依赖关系的资源中很关键。例如数据库连接和语句对象：
try (Connection conn = DriverManager.getConnection(url);
PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.execute();
} // 先 close(stmt)，再 close(conn)
如果反过来写成 PreparedStatement 在前、Connection 在后，stmt.close() 可能因 conn 已关闭而抛出异常（取决于驱动实现），但更严重的是逻辑上违反资源生命周期约束。
立即学习“Java免费学习笔记（深入）”；
其他注意事项：
- 每个资源分号分隔，末尾不能有逗号或分号
- 不能在括号内做赋值以外的操作（如
if (x != null) new FileInputStream(x)不合法） - 资源变量隐式为
final，不可在 try 块内重新赋值
异常抑制（Suppressed Exceptions）要主动检查
当 try 块抛出异常，且资源关闭时也抛出异常，后者会被“抑制”并附加到主异常上，不会丢失，但默认不打印。容易误以为关闭没出问题。
正确做法是调用 getSuppressed() 检查：
try (FileInputStream fis = new FileInputStream("a.txt")) {
throw new RuntimeException("read failed");
} catch (RuntimeException e) {
for (Throwable s : e.getSuppressed()) {
System.err.println("Suppressed: " + s);
}
}
常见被忽略点：
- 日志框架（如 Log4j）默认不输出 suppressed 异常，需配置或手动处理
- JUnit 测试中若只断言主异常，可能漏掉关闭阶段的真实失败原因
- IDE 调试时堆栈只显示主异常，需展开
suppressedExceptions字段查看
try-with-resources 不能替代 finally 中的清理逻辑
try-with-resources 只保证调用 close()，但不等于“清理完成”。比如文件锁未释放、线程未中断、缓存未刷新等，仍需在 close() 内部或额外逻辑中处理。
典型陷阱：
- 自定义资源的
close()方法为空或只关底层流，忽略了业务状态重置 - 使用 NIO 的
FileChannel或MappedByteBuffer，仅调用close()不一定立即释放内存映射，需配合Cleaner或反射调用sun.misc.Cleaner（不推荐） - 某些连接池（如 HikariCP）的
Connectionclose()实际是归还连接，不是真正关闭，不能依赖它做连接级清理
资源是否真关闭、何时关闭、关闭是否成功，得看具体实现，语法本身不做保障。
