try-with-resources彻底避免io资源泄漏的关键在于：所有资源必须显式声明在try括号内，按依赖关系逆序声明（底层流先、包装流后），确保lifo关闭顺序；构造异常可能导致半初始化泄漏，需配合files工具类或工厂方法规避；自定义类须实现autocloseable且close()幂等。
在 Java IO 流操作中，用好 try-with-resources 是防止资源泄漏最直接有效的方式，但“用了就安全”是常见误解。真正“彻底避免”，关键在于理解其机制边界、规避典型陷阱，并配合正确编码习惯。
确保所有 IO 资源都在 try 括号内声明
只有显式声明在 try(...) 括号里的资源，JVM 才会自动调用 close()。漏掉任意一环，泄漏风险立即出现。
- ✅ 正确：嵌套流全部声明（如
FileInputStream+BufferedInputStream+ObjectInputStream） - ❌ 错误：只声明外层流，底层流由构造函数内部创建（例如
new BufferedReader(new FileReader(...))中的FileReader未单独声明） - ⚠️ 注意：像
Files.newBufferedReader(Paths.get(...))返回的流也必须声明——它虽是工厂方法返回，但仍是AutoCloseable实例
严格遵循资源声明顺序与依赖关系
IO 流常呈链式依赖（缓冲流 → 字节流 → 文件句柄），关闭顺序错误会导致底层资源提前释放，引发 IOException 或静默失效。
- 后声明的资源先关闭（LIFO 原则），所以应按“从外到内”声明：先写包装流，再写被包装流
- 示例：
try (BufferedReader br = new BufferedReader(...); FileReader fr = new FileReader(...))❌ 错序 ——fr应在br之前声明，否则br.close()可能因fr已关而报错或无效 - 推荐写法：
try (FileReader fr = new FileReader("a.txt"); BufferedReader br = new BufferedReader(fr))✅ 保证br先关、fr后关
警惕构造阶段异常导致的半初始化泄漏
如果资源构造器（如 new FileInputStream()）抛出异常，该资源不会进入关闭队列；但如果它内部已成功分配系统句柄（如打开文件），而后续构造失败，句柄就可能泄漏。
- 典型场景：自定义复合资源类中，多个
new FileInputStream()分步执行，第二个失败时第一个已打开却无处关闭 - 解决方式：不在构造器中做资源分配；改用静态工厂方法 + 显式 try-with-resources 管理每一步
- 更稳妥做法：使用
Files工具类（如Files.lines()、Files.readAllLines()），它们内部已封装完整资源生命周期，无需手动管理
补充：自定义 IO 类务必实现 AutoCloseable
如果你封装了带缓冲区、线程池或本地句柄的 IO 工具类，必须实现 AutoCloseable 接口，并在 close() 中释放全部底层资源。
-
close()方法需幂等：多次调用不报错、不重复释放 - 捕获并记录内部
close异常，避免掩盖主异常；必要时抛出RuntimeException或封装为业务异常 - 避免在
try块内对资源变量重新赋值（如br = new BufferedReader(...)），这会使原始引用丢失，导致 JVM 关闭的是旧对象（可能已关）或 null
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
