java资源管理类必须实现autocloseable接口，close()需幂等、线程安全且抛出exception；构造失败须清理已分配资源，严禁在close()中重开资源或抛未检异常。
Java 资源管理类（如封装文件流、数据库连接、网络套接字等需显式释放资源的对象）应严格遵循 try-with-resources 兼容性设计 + AutoCloseable 实现 + 明确的生命周期语义。核心不是“怎么写”，而是“怎么避免泄漏、误用和时序错误”。
必须实现 AutoCloseable 接口
这是 JVM 识别可自动关闭资源的唯一标准接口。不要仅靠命名（如 close() 方法）或文档约定：
- 继承
AutoCloseable，而非仅实现自定义 close 接口 -
close()方法必须声明为public void close() throws Exception（允许子类抛出更具体的异常，如IOException） - 禁止在
close()中抛出未检查异常（如NullPointerException），除非是严重内部错误且已记录
close() 必须幂等且线程安全
多次调用 close() 不应报错或改变状态；多线程并发调用也应安全：
- 用 volatile boolean 标记是否已关闭，首次关闭后立即置位，后续调用直接返回
- 关闭逻辑（如关闭底层流、释放 native 句柄）放在同步块或使用原子操作保护关键段
- 若依赖外部资源（如 NIO 的
DirectByteBuffer），需确认其自身 close 是否幂等
构造失败时，不能留下半初始化资源
构造函数中若分配了需管理的底层资源（如打开了 FileInputStream），但后续初始化失败，必须主动清理：
- 在构造函数内使用 try-catch，捕获异常后立即 close 已创建的资源，再 rethrow
- 避免在构造函数中做复杂业务逻辑；把可失败操作移到 factory 方法或 builder 的 build() 中，便于统一清理
- 示例：new DatabaseConnection(url) 若连不上，不应让对象处于“已部分构造但不可用”状态
不替代 try-with-resources，但要兼容它
资源管理类不是为了绕过 try-with-resources，而是为了让 try-with-resources 能正确工作：
- 禁止在
close()中重新打开资源或重置状态（这违反 AutoCloseable 含义） - 若需复用，提供独立的
reset()或reopen()方法，并明确文档说明它不等价于 close + new - 在 JUnit 测试中，优先用 try-with-resources 验证 close 行为，而非手动调用 close() 后再访问资源
不复杂但容易忽略——重点不在语法，而在每个 close 调用背后是否真正释放了所有持有资源、是否经得起并发和重复调用考验。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
