Closeable在自定义变量包装流中的递归关闭逻辑

在Ja va的I/O世界里，自定义包装流（比如继承FilterInputStream或FilterOutputStream）是个挺常见的操作。但说到实现Closeable接口，尤其是处理递归关闭逻辑，这里面的门道可不少。一个不小心，资源泄漏、重复关闭或者异常处理不当的问题就找上门了。

简单来说，核心目标就一个：当你关闭包装流时，必须确保它直接持有的那个底层流也被正确关掉，而且整个过程得是单向的、幂等的，既不能重复关，也不能漏掉，还得妥善处理可能冒出来的IOException。

关闭责任，必须明确

首先得摆正心态：包装流不能当“甩手掌柜”。它不应该假设底层流“已经关了”或者“不该我管”，更不能把关闭的责任完全推给调用方。行业里的标准做法很明确：谁构造时传入了这个流，谁就负责在关闭时关掉它。 这也是JDK里FilterInputStream这些类一向遵循的设计。

具体操作时，有几个细节得留心：

• 如果底层流是null（虽然少见但确实合法），直接跳过关闭步骤，避免空指针异常。
• 如果底层流已经被关闭过，再次调用它的close()方法应该是幂等的——也就是啥也不干。好在JDK自带的流基本都满足这个特性。
• 切记，不要在构造函数里就急着把底层流关了，也别在close()方法之外的其他地方（比如read()、write()）去关闭它。关闭的时机和入口必须统一。

异常处理，讲究策略

Closeable.close()方法声明了会抛出IOException，因为关闭物理资源（比如文件句柄、网络连接）确实可能失败。这里的处理原则是：既不能因为底层流关闭失败，就中断了本层该做的清理工作；也不能图省事，把异常悄无声息地“吞”掉。

一个可靠的关闭流程通常是这样的：

• 首先，执行本层的资源释放。比如清空内部的缓冲区、释放可能持有的本地句柄等。
• 然后，再去尝试关闭底层流。如果底层流关闭时抛出了异常，应该优先保留并传播这个“第一个”异常。在Ja va 7及以上版本，利用try-with-resources语句的“suppressed exception”机制可以优雅地处理多个异常。
• 要特别小心finally块的使用。避免出现这样的情况：本层的close操作成功了，但底层流的close失败了，结果在finally块里用新异常覆盖了原本应该抛出的那个异常，导致问题被掩盖。

避开陷阱：重复关闭与循环引用

递归关闭听起来简单，但实际编码时容易踩坑。最关键的是要保证关闭动作沿着“包装链”单向向下，绝不能向上回溯或者横向触发其他不相关的流。

下面这几个是典型的“坑”：

• 多个包装流共享同一个底层流，并且各自都实现了close()。这会导致底层流被关闭多次，可能引发意料之外的IOException，或者在某些实现下静默失败。
• 包装流内部，通过回调、监听器等机制，间接持有了对自身的引用。关闭时可能意外触发另一条路径上的close调用，形成混乱。
• 在使用装饰器模式时，关闭入口没有统一。调用方分别去关闭外层流和内层流，破坏了单向关闭的原则。

怎么解决呢？核心思路是确保每个流实例的关闭权是唯一的。通常，这个责任会交给最外层的那个包装流。为了万无一失，可以引入一个AtomicBoolean closed标记位。在close()方法里，用compareAndSet确保只有第一个调用者能执行实际的关闭逻辑，后续调用直接返回，从而实现幂等性。

一份安全的参考实现

道理讲完了，来看一段典型的FilterInputStream子类的close()实现，关键点都体现在里面了：

private final InputStream in;
private final AtomicBoolean closed = new AtomicBoolean();

@Override
public void close() throws IOException {
    if (closed.compareAndSet(false, true)) {
        try {
            // 1. 先执行本层清理（例如：清空缓冲区）
            clearBuffer();
        } finally {
            // 2. 再递归关闭底层流 —— 确保单向、一次、幂等
            if (in != null) {
                in.close();
            }
        }
    }
}

这段代码清晰地展示了如何通过原子标记避免重复关闭，以及如何利用try...finally结构确保本层清理逻辑总会被执行，同时将底层流的关闭异常正确向上传播。