用于刷新和关闭包含另一个流或通道的流和通道的常规合同

Question

关闭和刷新IO资源非常重要，很少正确完成（至少我是这样）。这样做的原因是，大部分时间，它仍然可以正常工作。垃圾收集器关闭文件，这在大多数应用程序中不时发生。当流关闭时（可能也由垃圾收集器）或写入大量数据时自动完成刷新。

如果Java资源的生命周期与局部变量的生命周期一致，那么Java 1.7的try-with-resource可以更容易地关闭IO资源。如果他们应该，例如和其他一些对象一样生活，但这是另一个故事。

自从我开始编写足够复杂的程序以至于我需要使用包装其他资源的资源时，我发现很难确定要关闭和/或刷新的内容比 时那样做。在另一个资源中包装资源的示例是：

• 从InputStreamReader。
创建InputStream
• 从InputStream。
创建ReadableByteChannel
• 从DataOutputStream。
创建OutputStream
• 从PrintStream。
创建OutputStreamWriter或OutputStream

这可能也会发生多层深层次，例如ReadableByteChannel InputStream GZIPInputStream InputStreamReader BufferedReader中的flush()包裹close()做到这一点，但似乎有道理）。几乎总是包装和包装的资源应该具有相同的生命周期，如果可以在最外层的资源上进行刷新是最方便的，其中也进行了写入，因此只需要传递一个对象。

在这段时间里，我从未见过关于关闭和刷新如何与其他资源中包含的资源交互的令人满意的解释。我的假设如下：

• 刷新资源（即在其上调用InputStream）也会递归地刷新包装的资源，直到将数据推送到例如资源上。磁盘或网络。
• 关闭资源（即在其上调用OutputStream）也会递归关闭包装的资源，直到释放某些操作系统资源。

现在我的问题;在使用IO资源的JDK实现时，这些假设是正确的，特别是接口ReadableByteChannel，WritableByteChannel，Reader，Writer，{{1}}和{{1} }？

如果一个或两个假设完全不正确，那么哪些假设会更好？

如果这些假设并不总是正确的，那么实施的行为会有何不同，原因是什么？