Java中finally块的核心作用是提供确定性执行入口以确保清理逻辑不被跳过，它不管理资源所有权，仅履行已持有资源的释放义务；真正负责所有权与生命周期管理的是资源声明位置、AutoCloseable契约及try-with-resources机制。
Java中finally块的核心作用不是“管理资源所有权”，而是提供一个确定性执行入口，确保清理逻辑不被跳过。真正负责资源所有权归属与生命周期管理的，是资源声明的位置、接口契约（AutoCloseable）以及JVM的自动释放机制。
资源所有权应由声明位置决定，而非finally控制
资源对象一旦创建，其所有权就属于当前作用域。如果在try内声明（如FileInputStream fis = new FileInputStream(...)），该变量仅在try块内可见，finally根本无法访问——这直接导致关闭逻辑失效。正确做法是将变量声明在try外部，初始化为null，使finally能安全判空并操作：
- 资源变量必须在try-catch-finally结构之外声明（如方法局部变量）
- 初始化为null，避免未赋值引用引发NullPointerException
- try中完成实际创建；finally只负责“是否已创建”的判断和关闭动作
finally不拥有资源，只承担“尽责释放”义务
finally块本身不获取、不转移、不继承资源所有权。它只是开发者约定的“最后防线”，用于执行已持有资源的释放动作。这种释放不是所有权移交，而是履行资源使用者的契约责任：
- 若资源创建失败（如构造时抛出IOException），变量仍为null，finally中判空后跳过关闭
- 若多个资源需关闭，每个都必须独立判空+独立try-catch，防止前一个close()异常中断后续释放
- 不能在finally中重新赋值或return，否则会干扰主流程逻辑和异常传播
真正管理所有权的是try-with-resources语义
从Java 7起，try-with-resources才是资源所有权管理的标准范式。它通过编译器介入，将资源声明与生命周期绑定：
立即学习“Java免费学习笔记（深入）”；
- 资源必须实现AutoCloseable接口，close()方法即退出契约的唯一出口
- 资源在try括号内声明，作用域严格限制在该try块内，离开即触发close()
- JVM按“后声明先关闭”顺序调用close()，并自动压制（suppressed）关闭异常，不掩盖原始业务异常
- 本质上，这是对finally模式的语法糖封装，但把所有权管理交给了语言机制而非人工逻辑
何时仍需手动用finally？
并非所有资源都支持AutoCloseable，也并非所有场景都能用try-with-resources：
- 非AutoCloseable资源（如手动分配的本地内存、JNI句柄、某些老框架连接对象）
- 需要跨多个try块复用同一资源（如长连接复用），此时关闭时机需由业务逻辑控制
- 兼容Java 6及更早版本的遗留系统
- 资源关闭逻辑复杂（如需等待异步确认、回滚事务后再关闭），超出自动close语义范围
