finally块的核心价值是保障退出前的状态清理，无论正常执行、return、抛异常或break/continue，只要try/catch开始执行就必运行；用于资源释放（如关闭文件、连接）、状态重置（如解锁、清标志位），且不可return或throw以免覆盖返回值或压制异常。
finally块的核心价值，不是兜底异常，而是保障退出前的状态清理——无论代码是正常走完、中途return、抛出未捕获异常，还是被break/continue跳出，只要try或catch已开始执行，它就一定会运行。
资源释放：关闭文件、连接、锁等物理资源
Java有垃圾回收，但文件句柄、数据库连接、Socket、ReentrantLock等不属于内存范畴，必须显式释放。finally是最后的防线：
- 声明资源引用为null（如FileInputStream fis = null;），避免未初始化就调用close()
- 在finally中先判空，再套一层try-catch来关闭资源，防止close()自身抛出的IOException干扰主流程
- 不要在try块里直接close()——若写操作失败后close又出错，后续清理可能被跳过
状态重置：还原标记、解锁、清标志位
业务中常需设置中间状态（如isProcessing = true、lock.lock()），这些动作成功后才需要在finally中逆向操作：
- 状态重置逻辑应与设置逻辑“成对出现”，且依赖前置操作是否真正执行成功
- 避免在finally中做业务性写操作（如更新数据库字段），因其执行时机不可控，易引发数据不一致
- 若重置本身可能失败（如写配置文件失败），应捕获并记录日志，而非让异常穿透出去
避免覆盖返回值和压制异常
finally不是“随便写return的地方”，它的执行会直接影响方法行为：
立即学习“Java免费学习笔记（深入）”；
- try或catch中有return时，JVM先暂存返回值，再进finally；若finally也含return，原返回值会被完全覆盖
- finally中若抛出新异常，会压制try/catch中已发生的异常（原始异常丢失）
- 推荐做法：finally只做清理，不return、不throw；关闭资源时的异常应静默处理或记录，不向上抛
比try-catch-finally更优的替代方案
纯清理场景下，try-finally已足够；但现代Java更推荐升级写法：
- 优先使用try-with-resources：适用于实现AutoCloseable的资源，自动关闭、异常抑制机制完善
- 对不支持AutoCloseable的资源（如自定义锁、硬件开关），仍需靠finally手动管理
- 当清理逻辑复杂或需条件判断（如仅在加锁成功后才unlock），try-finally仍是不可替代的底层保障
