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 更可靠。
例如：
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
return reader.readLine();
} catch (IOException e) {
log.error("read failed", e);
throw new BusinessException("read error", e);
}
// close() 自动执行，且若 readLine() 和 close() 都抛异常，前者为主，后者被 addSuppressed
注意：
- 自定义资源类必须实现
AutoCloseable，且close()方法应幂等、快速、不抛非运行时异常 - 若必须手动管理（如老版本 JDK 或非
AutoCloseable对象），可将清理逻辑抽到私有方法中，在try/catch末尾显式调用，而非塞进finally
finally 中只保留最简资源释放动作
如果确实无法用 try-with-resources（比如要兼容旧 API 或需条件性关闭），finally 里只做一件事：调用 close() 或等效的释放方法，并包裹空的 catch —— 但仅限于 IOException 等已知低风险异常。
示例：
InputStream is = null;
try {
is = new FileInputStream("x.txt");
// ... do work
} finally {
if (is != null) {
try {
is.close(); // 唯一动作
} catch (IOException ignored) {
// 忽略，不记录日志也不 rethrow —— 因为它不能掩盖主流程异常
}
}
}
关键点：
- 绝不记录日志（
log.warn("close failed", e)会触发异步 appenders，可能引发新异常） - 绝不抛异常或
return - 先判空再调用，避免
NullPointerException - 不要在
finally里释放多个资源并链式调用（如a.close(); b.close(); c.close()）—— 应分别包裹独立try-catch
真正难的不是写对语法，而是克制住把“顺手加一句日志”“再校验下状态”的冲动——这些念头，几乎总是 bug 的起点。
