自定义变量包装流实现Closeable接口时，应由包装流负责递归关闭其直接持有的底层流，确保单向、幂等、不重复、不遗漏；需用AtomicBoolean标记关闭状态，先执行本层清理再关闭底层流，并正确处理IOException。
自定义变量包装流（如继承 FilterInputStream 或 FilterOutputStream）中实现 Closeable 接口时，递归关闭逻辑的核心是：**确保被包装的底层流在自身关闭时也被正确关闭，且不重复关闭、不遗漏关闭、不因异常中断传播**。
明确关闭责任归属
包装流不应假设底层流“已经关了”或“不需要关”，也不应把关闭责任完全推给调用方。标准实践是：**包装流自身负责关闭其直接持有的 delegate 流**（即构造时传入的那个流），这是 FilterInputStream/FilterOutputStream 等 JDK 类的既定行为。
- 若底层流为
null（极少见但合法），跳过关闭，避免 NPE - 若底层流已关闭，再次调用
close()应是幂等的（JDK 流基本都满足） - 不要在构造时提前关闭底层流，也不要在
close()外的任何方法中关闭它
正确处理关闭异常
Closeable.close() 声明抛出 IOException，但实际关闭过程中可能因底层资源问题失败。关键原则是：不因子流关闭失败而阻止本层清理逻辑执行，也不应吞掉异常。
- 先执行本层资源释放（如清空缓冲区、释放本地句柄等）
- 再尝试关闭底层流；若抛出异常，优先保留第一个异常（Java 7+ 可用 try-with-resources 的 suppressed exception 机制）
- 避免在
finally块中无条件覆盖主异常（例如：本层 close 成功，但 delegate close 失败，应传播后者）
避免双重关闭与循环引用
递归关闭只应沿“包装链”单向向下，不可向上回溯或横向触发其他无关流。常见陷阱包括：
- 多个包装流共享同一底层流，且各自实现
close()—— 这会导致重复关闭，可能引发IOException或静默失败 - 包装流内部持有对自身的引用（如通过回调、监听器），导致关闭时意外触发另一路 close 调用
- 使用装饰器模式时，未统一关闭入口，调用方分别关闭外层和内层流
解决方案：确保每个流实例有唯一关闭权，通常由最外层包装流承担最终关闭职责；必要时用 AtomicBoolean closed = new AtomicBoolean() 做关闭状态标记，首次 close() 后直接返回。
参考实现片段（安全递归关闭）
以下是一个典型 FilterInputStream 子类的 close() 实现要点：
private final InputStream in;
private final AtomicBoolean closed = new AtomicBoolean();
@Override
public void close() throws IOException {
if (closed.compareAndSet(false, true)) {
try {
// 本层清理（如清空缓冲区）
clearBuffer();
} finally {
// 递归关闭底层流 —— 单向、一次、幂等
if (in != null) {
in.close();
}
}
}
}
