finally块不能强制关闭资源，仅保证代码执行；常见失效原因是未判空、未捕获close()异常，导致NPE或异常中断后续关闭流程。
finally 块不能“强制”关闭资源，它只保证代码执行；是否真正关闭，取决于你写的 close() 逻辑是否健壮。
为什么 finally 里的 close() 经常没生效
常见错误是把 conn.close() 直接写在 finally 里，不判空、不捕获异常。一旦 conn 是 null，会抛 NullPointerException；如果 close() 自身抛 SQLException 或 IOException，又没 catch，整个清理流程就中断了——后面的 stmt.close()、rs.close() 全部跳过。
-
Connection、Statement、ResultSet等变量必须声明在try外（如Connection conn = null;），否则finally根本访问不到 - 关闭顺序必须是
ResultSet → Statement → Connection，反着关可能触发 “connection closed” 异常 - 每个
close()都要单独包一层try-catch，不能共用一个 —— 否则前一个失败，后一个就彻底不执行
finally 中 close() 的标准写法
以 JDBC 为例，正确结构是：
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
conn = DriverManager.getConnection(url);
stmt = conn.prepareStatement(sql);
rs = stmt.executeQuery();
// ...业务处理
} catch (SQLException e) {
// 处理主异常
} finally {
if (rs != null) {
try { rs.close(); } catch (SQLException e) { /* 记日志，不 throw */ }
}
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { /* 记日志，不 throw */ }
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { /* 记日志，不 throw */ }
}
}
- 每个资源都做
if (xxx != null)判空，避免NullPointerException -
close()的异常必须捕获，且不能向上抛出或return—— 否则会覆盖 try 块里的原始异常 - 日志建议用
logger.warn("关闭 ResultSet 失败", e)，而不是printStackTrace()
try-with-resources 真的比 finally 更可靠吗
是的，但前提是资源类型实现了 AutoCloseable（JDBC 4.0+ 的 Connection、Statement、ResultSet 都满足）。它自动按声明逆序调用 close()，且内部已处理了异常抑制（suppressed exception），不会掩盖主异常。
- 多个资源用分号隔开：
try (Connection c = ...; PreparedStatement s = ...) { ... } - 如果必须兼容 Java 6 或更老环境，
finally是唯一选择，但必须严格按上述模式手写 - 注意：自定义资源类若想支持 try-with-resources，必须实现
AutoCloseable并正确抛出异常
最容易被忽略的三个细节
一是 finally 块里写了 return 或 System.exit(0) —— 这会让整个方法提前退出，后续 close 语句根本不会运行；二是把多个资源塞进同一个 try-catch 关闭，一个失败就断链；三是忘了关闭嵌套资源，比如用 BufferedReader(new FileReader(...)) 时，只关 BufferedReader 不够，底层 FileReader 也得关 —— 而 try-with-resources 会自动递进关闭。
