finally块仅负责资源清理与状态还原，禁用return和throw；手动关闭资源需判空并捕获close异常；现代开发优先使用try-with-resources管理AutoCloseable资源。
异常分支配合 finally 块安全退出，核心是明确分工：try 负责业务执行与异常发现，catch 负责异常分类处理，finally 只做一件事——清理资源、还原状态，不干预返回逻辑、不抛新异常。
finally 必须避开的两个雷区
这两个行为会直接破坏方法退出的可预测性：
- 在 finally 中写 return：哪怕只是“return;”，也会覆盖 try 或 catch 中已确定的返回值。例如 try 返回 10、catch 返回 -1，只要 finally 有 return，调用方拿到的永远是 finally 的结果
- 在 finally 中 throw 异常：如果 try 已抛出 NullPointerException，而 finally 又抛出 IOException，原始异常会被彻底丢弃，调试时只能看到后者，问题根源被掩盖
资源关闭的标准写法
手动管理资源（如 FileInputStream、Connection）时，finally 是最后一道防线，但必须防住 close() 自身可能失败：
- 声明资源变量时初始化为 null，避免未成功创建就调用 close()
- 在 finally 中先判空，再用独立的 try-catch 包裹 close()，错误只记录日志，不向上抛
- 不要把 close() 放在 try 块里——若业务代码出错后 close 又失败，清理就中断了
状态重置要和前置操作严格配对
比如加锁后才需解锁、标记 isRunning = true 后才需在 finally 设为 false：
立即学习“Java免费学习笔记（深入）”；
- 解锁或清标志前，确认 lock.isHeldByCurrentThread() 或 isRunning 确实为 true，避免无效操作甚至 IllegalStateException
- 重置动作本身若可能失败（如写配置文件失败），捕获异常后仅打 warn 日志，绝不让其穿透 finally
- 避免在 finally 中做业务写操作（如更新数据库字段），因为执行时机不可控，易造成数据不一致
更现代的替代方案优先考虑
对于实现了 AutoCloseable 的资源，直接用 try-with-resources 更安全简洁：
- 自动调用 close()，无需手写 finally
- 若多个资源都关闭失败，主异常保留，次要异常被抑制（suppressed），可通过 getSuppressed() 查看
- 不支持 AutoCloseable 的资源（如自定义硬件开关、ReentrantLock），仍需靠 try-finally 手动保障
