finally 的核心价值是保证代码块必然执行，适用于解锁、状态标记、日志记录等兜底逻辑；资源释放优先用 try-with-resources，finally 仅适用于非 AutoCloseable 资源或状态重置等场景。
finally 适合做资源释放，但不是唯一或最推荐的方式；它的核心价值在于“无论是否异常都执行”，而非“专门用来关资源”。
finally 的本质作用：保证代码块必然执行
只要对应的 try 或 catch 块开始执行了（哪怕刚进 try 就 throw，或在 catch 中 return），finally 就一定会运行（除非 JVM 直接退出、线程被强制中断、或遇到 System.exit()）。这使它成为兜底逻辑的可靠载体。
- 适合放必须收尾的操作，比如解锁、标记状态为完成、记录退出日志
- 不适合放可能抛异常且无人捕获的逻辑——否则会掩盖原始异常
- return 语句在 try/catch 中执行后，仍会先跳进 finally 再真正返回（但注意：finally 中的 return 会覆盖前面的返回值）
资源释放用 finally？可行，但有明显缺陷
传统 try-catch-finally 确实能释放资源，例如：
InputStream is = null;try {
is = new FileInputStream("a.txt");
// 读取操作
} finally {
if (is != null) is.close(); // 手动判空+关闭
}
问题在于：
立即学习“Java免费学习笔记（深入）”；
- 模板代码冗长，易遗漏判空或写错顺序
- close() 自身可能抛 IOException，若在 finally 中未处理，会吞掉 try 块中的原始异常
- 多个资源需嵌套或重复判断，可读性和维护性差
现代写法：优先用 try-with-resources（JDK 7+）
所有实现 AutoCloseable 接口的资源（如 InputStream、Connection、Scanner）都支持自动管理：
try (FileInputStream is = new FileInputStream("a.txt");BufferedReader reader = new BufferedReader(new InputStreamReader(is))) {
// 使用资源
} // 自动按声明逆序调用 close()，即使发生异常也确保执行
优势包括：
- 语法简洁，资源声明即绑定生命周期
- close() 异常会被抑制（suppressed），不干扰主异常传播
- 编译器强制检查资源类型，避免忘记关闭
finally 的合理使用场景（非资源释放）
当需要与异常流程解耦的确定性行为时，finally 更显价值：
- 释放非 AutoCloseable 的本地资源，如 native 句柄、自定义锁（Lock.unlock()）
- 重置共享状态，比如将 ThreadLocal 清空、计数器减一
- 记录方法退出时间、埋点统计、清理临时文件路径（非流式资源）
- 在 AOP 或框架拦截中统一做上下文还原
