finally块不自动关闭资源，仅保证代码执行；需手动在其中判空、逐个try-catch关闭resultset→statement→connection，并避免throw或return，现代项目优先用try-with-resources。
finally块本身不关闭资源，它只是提供一个“总会执行”的位置；是否关得掉，取决于你写的代码是否健壮。当它失效或不可靠时，不能只等它，而要分场景切换策略。
finally根本没执行？先查这四类硬中断
不是代码写错了，而是程序被外力强行截断：
- System.exit() 或 Runtime.getRuntime().halt()：JVM立即终止，所有Java层逻辑（包括finally）跳过
- 无限循环或死锁卡在try/catch内：线程没走到finally语句，就永远停住了
- JVM崩溃级错误：如 OutOfMemoryError、StackOverflowError，运行时已失稳，不保证任何清理
-
操作系统强杀进程：比如 Linux 下
kill -9，JVM来不及响应任何钩子
资源还在，但finally里关失败了？这样兜底
常见于 close() 抛出 SQLException 或 IOException，又没捕获，导致后续资源全挂掉。正确做法是：
- 每个 close() 单独 try-catch：一个流关崩了，不影响另一个连接释放
- 关闭前判 null：避免 NullPointerException 中断清理流程
- 关闭顺序按依赖倒序：比如 ResultSet → PreparedStatement → Connection，或 InputStream → BufferedInputStream
-
异常至少记日志：不要静默吞掉，用
log.warn("关闭连接失败", e)留痕
更可靠的替代：用 try-with-resources 接管生命周期
Java 7+ 提供的语言级保障，比手写 finally 更安全简洁：
- 资源必须实现 AutoCloseable：InputStream、Connection、Scanner 等标准类都满足
-
声明即托管：资源写在
try (…)括号里，JVM 自动在退出时调用 close() - 多资源逆序关闭：后声明的先关，避免父资源提前释放导致子资源异常
- 异常不掩盖主异常：close() 抛错会作为 suppressed exception 附加到原始异常上，调用方仍可完整追溯
关键资源还需叠加防御层
对数据库连接、长链路网络通道等高价值资源，单靠语言机制不够：
-
设超时参数：如 HikariCP 的
connection-timeout，防卡死阻塞线程池 - 资源注册 + 定期扫描：把打开的 Connection/Socket 注册进全局管理器，后台线程定时检查未关闭项并告警（慎用于生产）
-
封装工具方法：如 Apache Commons IO 的
IOUtils.closeQuietly()，内部已做判空和异常捕获
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
