finally块总会在return、break、throw后执行，前提是try或catch已开始执行且未发生JVM强制终止；它在return表达式求值后、实际返回前运行，可覆盖原返回值或压制异常。
finally 块在 return、break、throw 后是否真能执行
能，只要 try 或 catch 块已开始执行，且未发生 JVM 强制终止（如 System.exit()、线程被 kill），finally 一定会执行——哪怕前面有 return、break、continue 或未捕获的异常。
常见误解是“return 一出，函数立刻结束”，其实 JVM 会暂存返回值，先跳进 finally，再完成返回。这点对资源清理至关重要。
-
finally在return表达式求值后、实际返回前执行（注意：若finally里也有return，它会覆盖原返回值） -
break/continue在循环中触发时，finally仍会在跳出前执行（适用于带try的循环体） - 若
finally抛出异常，它会压制try或catch中已有的异常（这是易踩坑点）
物理资源清理：文件句柄、数据库连接、Socket 等必须显式 close
Java 的 AutoCloseable 接口和 try-with-resources 是更优解，但 finally 仍是底层保障——尤其当资源不实现该接口，或需在关闭前做状态校验/日志记录时。
典型场景：打开文件后写入数据，无论成功失败都必须释放句柄；数据库连接必须归还连接池，否则快速耗尽。
- 不要在
try中直接close()：若close()抛异常（如网络中断），后续清理逻辑可能跳过 - 在
finally中调用close()，且对close()自身做try-catch（避免压制主异常） - 检查资源引用是否为
null：防止NullPointerException中断清理流程
FileInputStream fis = null;
try {
fis = new FileInputStream("data.bin");
// ... 读取操作
} finally {
if (fis != null) {
try {
fis.close(); // 关键：close 可能抛 IOException
} catch (IOException ignored) { /* 记录日志，但不抛出 */ }
}
}状态重置：为什么不能只靠 finally，还要配合 try-catch 的分工
finally 负责“无论如何都要做的事”，但不负责“判断是否需要重置”。比如一个锁标记 isLocked，仅当加锁成功才需在 finally 中解锁；若构造锁对象就失败，finally 里解锁反而引发 NPE。
状态重置常依赖前置操作的执行结果，因此需把“设置状态”和“重置状态”配对放在同一作用域内管理。
- 将可变状态（如
isProcessing、retryCount）的修改与清理逻辑绑定：在try开头设标志，在finally中清除 - 避免在
finally中修改业务关键状态（如更新数据库字段），因其执行时机不可控，可能造成数据不一致 - 若重置逻辑本身可能失败（如写回配置文件），应明确捕获并记录，而非让异常穿透出去
finally 里 throw 或 return 会掩盖原始异常或返回值
这是最隐蔽也最危险的问题：一旦 finally 块主动抛出异常或执行 return，JVM 会丢弃 try 或 catch 中已产生的异常/返回值。
例如，try 中读文件失败抛 IOException，finally 关闭流时又抛 NullPointerException，调用方只会看到后者——原始错误信息丢失。
- 绝对避免在
finally中使用return（除非你清楚自己在覆盖返回值） -
finally中抛异常必须用try-catch捕获并处理（如打日志），禁止向上抛 - 若必须报告
finally中的错误，可用addSuppressed()将其附加到主异常上（Java 7+）
复杂点在于：有些框架（如 Spring AOP）的环绕通知也会插在方法前后，和 finally 的执行顺序叠加后，状态清理可能被意外延迟或跳过——这时应优先考虑用 @PreDestroy、Closeable 实现或显式 shutdown 钩子替代嵌套的 finally 逻辑。
