在try-with-resources中，嵌套包装流子流close失败会中断父流清理、引发资源泄漏或异常掩盖；需通过幂等close、静默处理预期异常及逆序正确声明来应对。
在 try-with-resources 中，当嵌套包装流（比如 BufferedInputStream 包裹 FileInputStream）的子流（底层流）close() 失败时，父流（包装流）的关闭行为本身不会“失败”，但整个资源释放链可能被破坏，导致资源泄漏、异常掩盖或二次异常。
子流 close 失败会中断父流的正常清理逻辑
包装流通常在自己的 close() 中调用被包装流的 close()。如果子流的 close() 抛出异常（如 IOException），而父流未做防护处理，就会：
- 提前退出父流的关闭流程，跳过自身其他清理动作（如清空缓冲区、释放内部引用）
- 若父流
close()方法未声明 throws，可能把异常转为RuntimeException，掩盖原始问题 - 某些老版本工具类甚至会在子流已关闭后，还试图操作其内部 buffer，引发
NullPointerException或重复关闭异常
异常压制机制会让真正的问题被隐藏
当 try 块中已有业务异常（如读取时抛 IOException），而子流 close() 又失败，该失败会被作为 suppressed 异常附加到主异常上。但：
- 默认日志或
e.printStackTrace()在部分环境不显示 suppressed 部分 - 开发者只看到“读取失败”，却不知道“文件句柄根本没释放”，造成资源泄漏误判
- 若多个嵌套层都失败，只有第一个 close 异常成为主异常，其余全被压制，排查难度陡增
关闭顺序不当会放大子流失败的风险
try-with-resources 按声明逆序关闭：后声明的先关。若写成：
立即学习“Java免费学习笔记（深入）”；
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedInputStream bis = new BufferedInputStream(fis)) { ... }
则 bis.close() 先执行 → 内部调用 fis.close()；若此时 fis.close() 失败：
-
bis.close()可能因异常中断，未完成自身缓冲区 flush - JVM 仍会继续调用
fis.close()（第二次），触发重复关闭异常（如 “Stream closed”） - 若
bis.close()已抛异常，fis.close()的异常会被压制，主堆栈里看不到底层句柄泄漏根源
应对方式不是绕开 try-with-resources，而是加固流实现
关键在于让子流和父流都符合 AutoCloseable 规范：
- 子流
close()应幂等：已关闭状态下再次调用不抛异常，直接返回 - 父流
close()应捕获子流异常并静默处理（如SocketException: socket closed），仅对严重失败（如 flush 数据丢失）才重新抛RuntimeException - 必要时加适配器：用
AtomicBoolean记录关闭状态，synchronized+try-catch包裹所有清理逻辑 - 单元测试中显式调用多次
close()，结合OperatingSystemMXBean验证文件句柄是否真实释放
