优先用try-with-resources替代finally释放资源，因其自动按序关闭AutoCloseable资源、抑制close异常、避免资源泄漏；若必须用finally，则需外部声明变量、判空并独立try-catch关闭每个资源。
在finally块中释放资源，核心目标是“确保执行、不掩盖异常、不引发新问题”。但更关键的一点是：优先不用finally——改用try-with-resources。它更安全、更简洁、更符合现代Java实践。
为什么finally容易出错
手动写finally释放资源，常见隐患包括：
- 多个资源时，前一个close()抛异常，后续资源直接跳过，造成泄漏
- 资源变量在try内声明，finally里访问不到（作用域错误）
- 忘记判空，null引用调用close()触发NullPointerException
- close()本身可能抛IOException，未捕获会吞掉原始业务异常
- finally里写了return或throw，干扰正常流程和异常传播
必须用finally时的硬性规则
仅在兼容老JDK（
- 资源变量声明在try外部，初始化为null
- 每个资源独立判空：if (resource != null)
- 每个close()单独套一层try-catch，异常只记录不抛出
- 绝不写return、throw、System.exit()等中断语句
真正推荐的做法：用try-with-resources
Java 7起全面支持，适用于所有实现AutoCloseable的资源（FileInputStream、Connection、Scanner、BufferedReader等）：
立即学习“Java免费学习笔记（深入）”；
- 资源在try后括号内声明，自动管理生命周期
- JVM保证按“后声明先关闭”顺序执行close()
- 即使try块抛异常，close()异常会被压制（suppressed），主异常仍可捕获
- 代码量减少约50%，逻辑清晰，基本杜绝泄漏
小结：原则不是“怎么写finally”，而是“尽量别写finally”
try-with-resources不是语法糖，它是JVM层面的资源保障机制。只要资源类型支持AutoCloseable，就该无条件选用。finally只是兜底手段，不是首选方案。
