try-finally 是最轻量可靠的资源释放结构，适用于lock.unlock、手动关闭非idisposable资源等场景；finally块只做清理，须按逆序释放多资源并判空，不适用using/try-with-resources时必须退回原生try-finally。
当只需确保资源释放、不关心异常捕获时，try-finally 是最轻量、最可靠的结构。它不介入异常传播路径，只专注“无论如何都要执行清理”，特别适合 Lock.unlock、手动关闭非 IDisposable 资源、状态回滚等场景。
核心原则：finally 块必须只做清理，不做业务逻辑
finally 中的代码应严格限于释放资源或恢复状态，避免调用可能抛异常的业务方法，否则容易掩盖原始异常或引发不可控行为。
- ✅ 正确：调用 Lock.unlock()、stream.close()（已判空）、flag = false
- ❌ 错误：在 finally 里重试网络请求、写日志（若日志系统不稳定）、修改共享数据结构
- ⚠️ 注意：unlock() 本身通常不会抛异常，但若使用的是带校验的锁（如 ReentrantLock 的 lockInterruptibly 后 unlock），仍建议包裹空 try-catch 防意外（仅针对 close/unlock 类操作）
多资源释放：扁平化优于嵌套
多个需释放的资源（如 lock + stream + counter）不应层层嵌套 try/finally，而应在同一 try 块中获取，在同一 finally 块中按逆序释放。
- 先获取 lock → 再打开 stream → 最后递增计数器
- finally 中按相反顺序：counter-- → stream.close() → lock.unlock()
- 每个释放动作独立判空或加防护，例如 if (stream != null) stream.close();
与 using / try-with-resources 的边界划分
using（C#）和 try-with-resources（Java）本质是 try-finally 的语法糖，但仅适用于实现了 IDisposable / AutoCloseable 的类型。一旦遇到以下情况，就必须退回原生 try-finally：
- 资源类型未实现标准接口（如自定义锁、信号量、内存映射缓冲区）
- 需要在释放前执行条件判断（如 if (lock.isHeldByCurrentThread()) lock.unlock();）
- 释放逻辑含副作用控制（如只在特定错误码下才 unlock）
- 跨语言互操作或遗留系统中无法引入 RAII 机制
常见陷阱与规避方式
看似简单，但几个细节极易出错：
- 变量作用域问题：声明资源变量必须在 try 外（C#、Java 均要求），否则 finally 不可见
- 释放前未判空：尤其在初始化可能失败时（如 new Stream() 抛异常），变量仍为 null，直接调用 close() 会 NPE
- finally 中 throw 或 return：会终止当前方法、吞掉 try 中的异常或返回值，绝对禁止
- 忽略 unlock 的可重入性：多次 unlock 可能抛 IllegalMonitorStateException，应确保与 lock 次数严格匹配，或用 try-finally 封装成安全 unlock 工具方法
