Java释放资源应优先用try-with-resources：它通过编译器插入逆序关闭逻辑，保留主异常并提供getSuppressed()获取抑制异常；finally仅用于非AutoCloseable资源或跨方法场景，需判空和嵌套捕获以防掩盖异常。
Java中释放资源的关键在于“确定性”——必须确保关闭动作一定发生，且不掩盖原始错误。传统try-catch-finally和现代try-with-resources都能做到，但设计目标、安全性和可维护性差异明显。
finally块的核心作用与风险点
finally块保证清理代码执行，无论try中是否抛异常、是否return，甚至catch后也照常运行。但它不是“自动资源管理”，而是“手动兜底机制”：
- 资源变量需提前声明为null，否则作用域不可见
- 关闭前必须判空，否则空指针风险高
-
close()自身可能抛异常（如IOException），必须再套一层try-catch，否则会覆盖主异常 - 若finally中抛出新异常，原异常会被丢弃，调试时难以定位根本问题
try-with-resources的底层保障逻辑
它不是语法糖，而是编译器级资源生命周期控制。所有资源必须实现AutoCloseable，JVM在字节码层面插入隐式finally调用：
- 资源按声明逆序关闭：先声明的后关，避免依赖链断裂（如BufferedInputStream要晚于FileInputStream关闭）
- 即使try块抛异常，close()仍会执行；若close()也抛异常，原异常保留为主异常，新异常通过
getSuppressed()获取 - 无需判空、无需嵌套try-catch，资源初始化失败时不会进入try块，也不会触发close
何时该用finally而非try-with-resources
并非所有场景都适用自动管理：
立即学习“Java免费学习笔记（深入）”；
- 资源类未实现
AutoCloseable（如某些老框架自定义连接对象） - JDK版本低于7，无法使用该语法
- 需要在资源关闭前做额外判断或延迟关闭（如连接池归还逻辑不能简单调close）
- 资源生命周期跨多个方法，无法在单个try块内完成全部使用
混合使用的实用建议
现实项目中常需兼顾兼容性与安全性：
- 优先用try-with-resources处理标准IO、JDBC等已实现AutoCloseable的资源
- 对遗留代码中的非AutoCloseable资源，用finally+判空+嵌套捕获，并记录close异常为warn级别日志
- 自定义资源类务必实现AutoCloseable，close()中避免抛检查异常（可转为RuntimeException或静默处理）
- 单元测试中模拟close失败场景，验证主业务异常是否仍能被捕获并传播
