finally里写复杂逻辑危险，因其执行时机不可控且不参与返回值计算，易掩盖异常、篡改返回值或引发死锁；禁用close()、修改返回值、I/O操作、启线程等高危行为。
finally 里写复杂逻辑为什么危险
因为 finally 块的执行时机不可控：它会在 try 或 catch 中的 return、throw、甚至 System.exit() 之前强制执行，但又不参与方法的返回值计算。一旦你在 finally 里调用可能抛异常的方法（比如 close()）、修改返回值、或执行耗时/阻塞操作，就极易掩盖原始异常、改变预期返回、甚至引发死锁或线程挂起。
哪些“复杂逻辑”绝对不该放进 finally
以下操作在 finally 中属于高危行为，应立即移出：
-
finally中调用可能抛IOException的resource.close()—— 若try已抛出异常，此处再抛异常会吞掉原异常 - 在
finally中对返回变量重新赋值（如result = "fallback"），会导致try中的return result;失效 - 执行网络请求、数据库查询、日志同步刷盘等 I/O 操作 —— 可能超时、阻塞主线程、或因资源不可用而失败
- 启动新线程、调用
Thread.sleep()、或依赖外部状态（如检查某个 volatile 标志位）
更安全的替代方案：try-with-resources + 显式错误处理
Java 7+ 的 try-with-resources 自动管理实现了 AutoCloseable 的资源，把关闭逻辑从 finally 中解耦出来，且能正确抑制次要异常（通过 addSuppressed()）。
try (FileInputStream fis = new FileInputStream("data.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
return reader.readLine();
} catch (IOException e) {
logger.error("读取文件失败", e);
throw new BusinessException("内容加载异常", e);
}
如果必须手动释放非 AutoCloseable 资源（如某些老版 JDBC 连接池的连接），把清理逻辑封装成独立方法，并在 catch 和正常流程末尾分别调用，而不是塞进 finally。
立即学习“Java免费学习笔记（深入）”；
如果真要写 finally，只做三件事
真正适合留在 finally 中的，仅限于无副作用、不抛异常、不依赖上下文的原子操作：
- 将某个
volatile boolean标志重置为false（如inProgress = false） - 调用
Lock.unlock()—— 但前提是已确认该锁确实被当前线程持有（避免IllegalMonitorStateException） - 清空本地线程变量：
ThreadLocal.remove()（注意不是set(null)）
哪怕只是加一行日志，也优先考虑放在 catch 块末尾或方法出口前 —— finally 不是兜底日志区，而是最后防线，得足够轻。
