finally块中close()不生效主因是close()自身可能抛异常导致原始异常被压制，或资源为null/已关闭引发npe/ise；应判空关闭、内层捕获异常、禁用return/throw；推荐try-with-resources自动管理autocloseable资源；非autocloseable资源需手动在finally中安全释放；finally不保证执行，jvm强制退出、线程被杀、死循环时会跳过。
finally 块里调用 close() 为什么有时不生效
因为 close() 方法本身可能抛出异常，如果 try 块已发生异常，而 finally 中又抛出新异常，原始异常会被压制（suppressed），且资源实际未关闭。更关键的是：如果 close() 调用前资源引用为 null 或已提前关闭，直接调用会触发 NullPointerException 或 IllegalStateException。
实操建议：
- 始终在
finally中判空再关闭：if (resource != null) resource.close(); - 把
close()放进内层try-catch，避免干扰外层异常传播 - 不要在
finally中 return 或 throw，否则会吞掉 try/catch 的异常或返回值
Java 7+ 推荐用 try-with-resources 替代 finally
try-with-resources 是编译器支持的语法糖，自动调用实现了 AutoCloseable 接口的对象的 close() 方法，无论是否异常都会执行，且能正确处理多个资源的关闭顺序和异常压制。
使用场景：所有标准 I/O 类（FileInputStream、BufferedReader）、JDBC 类（Connection、Statement、ResultSet）都实现了该接口。
立即学习“Java免费学习笔记（深入）”；
示例：
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
br.readLine();
} catch (IOException e) {
// 异常在这里被捕获
}
注意：资源声明必须在 try 括号内，且按声明逆序关闭（后声明的先关）。
finally 中释放非 AutoCloseable 资源怎么办
比如手动分配的 native 内存（通过 Unsafe.allocateMemory）、自定义锁（ReentrantLock）、线程池（ExecutorService）等，不实现 AutoCloseable，无法用 try-with-resources。
实操建议：
- 对
ReentrantLock：必须在finally中调用unlock()，且确保 lock 成功后再进finally - 对
ExecutorService：调用shutdown()+awaitTermination()，但注意后者会阻塞，生产中常改用shutdownNow()配合超时判断 - 对 native 资源：务必在
finally中显式释放，并考虑用Cleaner（Java 9+）作为兜底机制
finally 不是万能的——它不保证一定执行
绝大多数情况下 finally 会执行，但有三个明确例外：
- JVM 进程被强制终止（如
System.exit(0)、kill -9） - 线程在
try或catch中被杀死（Thread.stop()，已废弃但仍有影响） - 死循环或无限递归卡死在
try块中，导致程序无法到达finally
这意味着：关键清理逻辑（如解锁、回滚事务）不能只依赖 finally，必要时需结合超时、健康检查或外部监控机制。尤其在分布式或长时间运行的服务中，finally 的“一定执行”是个脆弱假设。
