finally块在多重返回环境下必然执行且决定最终返回值：只要线程未被强制终止，它就一定运行；若含return语句，则覆盖try/catch中的返回，最外层finally的return生效；建议仅用于资源清理，避免return以保可读性与安全性。
finally块在多重返回环境下，行为是确定且可预测的：只要线程未被强制终止，它就一定执行；若其中包含return语句，则直接决定方法的最终返回值，覆盖try或catch中的任何返回。
finally执行的确定性前提
只要当前线程还在运行，且未调用System.exit()、Runtime.getRuntime().halt()，或被已废弃的Thread.stop()强行中断，finally就必然执行——无论异常是否抛出、是否被捕获、是否在try/catch中已有return。
- 即使try里发生未捕获异常（如
NullPointerException），finally仍会执行 - 即使catch块中已写
return，JVM也会先跳入finally执行完，再考虑返回 - 多个嵌套try-catch结构中，每个对应层级的finally都按作用域顺序独立执行
返回值由最外层finally决定
当多个finally块共存（例如catch内嵌try-finally，外层还有finally），返回值取最外层finally中的return表达式，内层finally的return会被忽略（除非它本身已提前终止该方法）。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 示例中两个finally都有return：第一个return 1，第二个return 2 → 最终结果为2
- 编译器实际将finally逻辑“内联”到所有可能出口前，相当于在每个return路径上插入其代码
- 这种覆盖是单向的：finally能改返回值，但不能改变try/catch中已完成的对象状态（如修改StringBuilder内容有效，但替换引用无效）
不建议在finally中写return
虽然语法允许，但会显著降低代码可读性和维护性：
- 掩盖真实业务逻辑的退出点，让调试和单元测试更困难
- IDE通常会发出警告（如IntelliJ提示“Finally block contains return statement”）
- 容易引发意外行为：比如资源清理逻辑被return打断，或与try/catch的语义产生冲突
- 正确做法是仅在finally中做清理（close流、unlock锁等），把返回逻辑留在try或catch中
多线程环境下的注意事项
finally的“必执行”特性在线程内部依然成立，但它不提供跨线程保障：
- 每个线程的finally只对本线程打开的资源负责（如本线程创建的FileInputStream）
- 若多个线程共享静态资源（如static FileOutputStream），需额外同步（synchronized或ReentrantLock）
- 推荐使用ThreadLocal隔离资源，避免竞争；或改用try-with-resources自动管理
- 线程被interrupt()时，finally仍执行；但若线程处于WAITING/TIMED_WAITING状态且未响应中断，可能延迟执行
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
