finally 是资源清理的兜底保障，确保非内存资源在任何执行路径下安全释放；优先用 try-with-resources 替代手写 finally；复杂对象销毁需分层协作并按依赖反序执行。
处理复杂对象生命周期中的 finally 清理，核心是确保非内存资源（如文件、连接、线程）在任何执行路径下都被安全释放——哪怕发生异常、提前返回或流程中断。
finally 是资源清理的“兜底保障”
finally 块只要 try 开始执行，就一定会运行（除非 JVM 强制退出或断电）。它不依赖异常是否被 catch，也不受 return、break 或 continue 影响。这意味着：即使业务逻辑中途抛出异常、方法提前返回，清理代码仍能执行。
- 适合关闭流、释放锁、注销监听器、关闭数据库连接等必须执行的操作
- 避免只在
try结尾写close()——一旦中间抛异常，这行代码就被跳过 - 注意：不要在
finally中写return，否则会覆盖try或catch的返回值，造成逻辑混乱
手动清理要兼顾空指针与重复关闭
直接在 finally 中调用 close() 很常见，但容易出错：
- 资源变量可能为
null（比如构造失败），调用close()会触发NullPointerException - 某些资源（如
InputStream）多次close()虽不报错，但属于冗余操作；而有些自定义资源重复关闭可能引发状态异常 - 建议模式：先判空，再关闭，并捕获关闭过程中的异常（通常仅记录，不抛出）
例如：
try {
FileInputStream fis = new FileInputStream("data.txt");
// 读取操作
} finally {
if (fis != null) {
try { fis.close(); } catch (IOException e) { /* 记录日志 */ }
}
}
优先用 try-with-resources 替代手写 finally
Java 7 引入的 try-with-resources 是更简洁、更安全的替代方案，适用于所有实现 AutoCloseable 的资源（如 InputStream、Connection、Scanner 等）。
立即学习“Java免费学习笔记（深入）”；
- 资源在
try语句结束时自动关闭，无需显式finally块 - 即使
try块中抛出异常，资源仍会被关闭；若关闭本身也抛异常，它会被抑制（suppressed），主异常仍可被捕获 - 代码更短、意图更清晰，且天然规避空指针和重复关闭问题
示例：
try (BufferedReader br = new BufferedReader(new FileReader("log.txt"))) {
String line;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
// 处理读取异常
}
复杂对象销毁需分层协作
当对象内部持有多个资源（如一个服务类同时管理线程池、缓存容器、数据库连接），单靠 finally 不足以完成完整清理：
-
finally适合局部、短生命周期资源的即时释放（如单次 IO 操作） - 对于长生命周期的复合对象，应结合框架生命周期管理（如 Spring 的
@PreDestroy）或显式销毁方法（如shutdown()） - 销毁逻辑要按依赖顺序反向执行：先停线程池，再清缓存，最后关连接，避免资源被提前释放后其他组件还在访问
