try-catch-finally 中资源释放常见失效场景有四：一是try中异常未捕获导致close不执行；二是catch或finally中抛新异常覆盖原始异常；三是资源初始化失败致变量为null，finally中未判空调用close引发NullPointerException；四是finally中throw或return劫持控制流。Java 7+应优先使用try-with-resources自动管理资源。
try-catch-finally 里资源释放的常见失效场景
直接在 try 块末尾调用 close() 或 dispose()，看似合理，但一旦 try 中抛出异常且未被捕获，后续语句根本不会执行；更隐蔽的是，如果 catch 块里又抛了新异常，finally 虽然仍会执行，但若它自己也抛异常（比如 file.close() 失败），就会覆盖原始异常，导致调试困难。
finally 中必须判空再释放资源
finally 不是万能保险——如果资源初始化失败（比如 new FileInputStream("missing.txt") 抛 FileNotFoundException），变量可能仍为 null，此时直接调用 close() 会触发 NullPointerException，掩盖原始错误。
务必检查资源引用是否非空：
FileInputStream fis = null;
try {
fis = new FileInputStream("data.txt");
// ... 读取操作
} catch (IOException e) {
// 处理读取异常
} finally {
if (fis != null) { // 关键：判空
try {
fis.close();
} catch (IOException e) {
// 记录 close 失败，但不 throw，避免吞掉主异常
System.err.println("Failed to close file: " + e.getMessage());
}
}
}
Java 7+ 推荐用 try-with-resources 替代手写 finally
手动管理容易漏判空、忽略关闭异常、嵌套多资源时逻辑臃肿。只要资源实现 AutoCloseable（如 FileInputStream、BufferedReader、Connection），优先用 try-with-resources：
- 自动在作用域结束时调用
close()，无需判空 - 多个资源用分号分隔，按声明逆序关闭
- 即使 try 块抛异常，close 异常会被抑制（suppressed），主异常仍可捕获
示例：
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
String line = br.readLine();
// ... 处理
} catch (IOException e) {
// 这里拿到的是 try 块的异常，close 错误可通过 e.getSuppressed() 查看
}
finally 里不要 throw 或 return
在 finally 中 throw 新异常或写 return，会强行终止当前方法流程，导致 try 或 catch 中已准备好的返回值或异常被丢弃。这是极难排查的逻辑覆盖问题。
正确做法是：
- 仅做清理：关闭、释放、重置状态
- 记录关闭失败日志，但不抛出
- 绝不修改方法的控制流（不
return、不throw）
哪怕 close() 抛 IOException，也应捕获并吞掉（或记录），否则你永远不知道原始业务异常到底是什么。
真正麻烦的不是“要不要放 finally”，而是资源初始化失败时变量为 null、close 自身失败时又抛异常、以及 finally 悄悄劫持了 return 值——这些细节不处理，try-catch-finally 就只是看起来安全。
