Java中保障资源安全释放的关键是严谨的异常处理与关闭逻辑：需判空再close、逐个捕获关闭异常、优先使用try-with-resources，finally并非绝对可靠。
Java 中的 try-catch-finally 是保障资源安全释放的基础手段，但写得不严谨反而会掩盖异常、引发空指针，甚至导致资源泄漏。关键不在“用了没用”，而在“怎么释放才真正可靠”。
资源释放必须判空再调用 close()
资源变量（如 FileInputStream、BufferedReader）在初始化失败时可能为 null。如果 finally 中直接调用 close()，就会抛出 NullPointerException，把原始异常（比如 FileNotFoundException）彻底盖住。
正确做法是：先检查非空，再执行关闭，并捕获 close 自身可能抛出的异常，但不向上 throw：
- 声明资源变量时初始化为 null
- finally 中用 if (resource != null) 判断
- close() 外层套 try-catch，仅记录错误，不中断主流程
多个资源需逐个判空、分别关闭
一个方法里打开文件流 + 数据库连接 + 网络 Socket 时，不能只关第一个就完事。任一资源未释放，都可能造成句柄耗尽或连接泄漏。
立即学习“Java免费学习笔记（深入）”；
传统写法要为每个资源单独判空、嵌套 try-catch，代码冗长易漏。例如：
- fileReader 和 bufferedReader 都要各自判空
- 关闭顺序建议按打开逆序（后开先关），尤其涉及包装流时
- 每个 close() 异常都应独立捕获，避免一个失败影响后续关闭
优先使用 try-with-resources 替代手写 finally
Java 7+ 提供的 try-with-resources 是更安全、简洁的替代方案，只要资源实现 AutoCloseable 接口（FileInputStream、Connection、Scanner 等均支持）。
它自动完成三件事：
- 作用域结束时自动调用 close()，无需手动写 finally
- 自动判空，不会因初始化失败触发 NullPointerException
- 若 try 块和 close() 都抛异常，后者作为 suppressed exception 附加到主异常上，可通过 e.getSuppressed() 查看，不丢失原始错误上下文
finally 不是“万能兜底”，有执行边界
finally 几乎总能执行，但以下情况会导致它跳过：
- try 或 catch 中调用了 System.exit()
- JVM 崩溃、线程被强制终止（如已废弃的 Thread.stop()）
- 发生无限循环或死锁，程序卡在 try/catch 里无法退出
因此，对关键资源（如数据库事务提交/回滚），不能仅依赖 finally ——必要时应在 try 结束前主动释放，或结合超时机制兜底。
