finally里写复杂逻辑危险，因其执行时机不可控且会覆盖原始异常或返回值；应仅保留无副作用的原子资源释放操作，其余逻辑移至catch后或用try-with-resources替代。
finally 里写复杂逻辑为什么危险
因为 finally 块的执行时机不可控：它会在 try 或 catch 中的 return、throw、甚至 System.exit() 之前强行插入执行，但不保证执行成功。一旦 finally 里抛出异常、调用 return、或发生死循环，就会覆盖原始异常或返回值，导致行为完全偏离预期。
常见现象包括：
-
try中抛了NullPointerException，finally又抛IOException→ 外层只看到后者，前者被吞掉 -
try中return "ok"，finally里也return "fail"→ 实际返回"fail"，且无任何警告 -
finally调用一个可能阻塞的资源关闭方法（如socket.close()），网络卡住 → 整个方法无限挂起
哪些操作算“复杂逻辑”，应从 finally 中移出
只要不是「确定不会失败、不改变控制流、不依赖外部状态」的操作，都算复杂。Java 规范建议 finally 仅用于资源释放类的原子动作。
以下操作必须移出 finally：
立即学习“Java免费学习笔记（深入）”；
- 调用非
close()类方法（如log.info()、notifyAll()、updateStatus()） - 涉及 I/O、网络、数据库交互（如
fileWriter.flush()、httpClient.send()） - 包含条件判断、循环、对象构造（如
new ArrayList()、if (x != null) x.destroy()） - 任何可能抛受检异常（
IOException等）且未在finally内捕获处理的操作
正确做法是：把这类逻辑移到 catch 后、finally 前，或封装成独立方法并在外层统一处理。
替代方案：用 try-with-resources + 显式清理更安全
Java 7+ 的 try-with-resources 自动调用 AutoCloseable.close()，且异常压制机制（addSuppressed()）能保留原始异常，比手写 finally 更可靠。
