输入流被 GC 处理

Question

我知道如果我做类似的事情，

copyFromInToOut(new FileInputStream(f1), new FileOutputStream(f2));
System.gc();

它将在那些 FileInputStream 上运行 GC，并关闭它们。但是，如果我这样做，

copyFromInToOut(new BufferedInputStream(new FileInputStream(f1)), new BufferedOutputStream(new FileOutputStream(f2));
System.gc();

是否存在 FileOutputStream 在 BufferedOutputStream 之前被 GC 的危险，不会导致缓冲区刷新？ 我不能调用flush、close，因为这需要比这更多的步骤。它首先涉及声明一个缓冲输入流，传递，然后调用 close。或者我这样做安全吗？

Answer 1

不要显式调用 System.gc()。不要依赖终结器来做任何事情。特别是如果您不了解垃圾收集的工作原理。可以忽略显式垃圾收集请求，并且终结器可能永远不会运行。

编写良好的流的 copyFromInToOut 方法可能会在内部使用其自己的缓冲区，因此不需要包装输出。

声明 FileInputStream 和 FileOutputStream 的变量，并在 finally 块中对每个变量调用 close()：

FileInputStream is = new FileInputStream(f1);
try {
  FileOutputStream os = new FileOutputStream(f2);
  try {
    copyFromInToOut(is, os);
    os.flush();
  } finally {
    os.close();
  }
} finally {
  is.close();
}

Answer 2

据我所知，当GCd 时，没有任何InputStream 实现会close() 为您服务。你必须close()手动输入流。

编辑：显然FileInputStream在我不知道的finalize方法中为你做了close()，但是请参阅其他答案，了解为什么您不应该依赖于此。

在上面的两个示例中，您必须关闭输入和输出流。对于包装的缓冲区情况以及任何包装的情况，您应该只需要在最外层的 InputStream 上调用 close()，在本例中是 BufferedInputStream代码>

Answer 3

分析当您这样做时到底发生了什么很有趣，只是不要这样做。

始终明确关闭您的流。

（回答你的问题，是的，当GC发生并且它们丢失时，缓冲区中的字节可能没有被刷新到文件I/O流）

Answer 4

应使用 @erickson 的答案中显示的模式显式关闭流。依靠终结来关闭流是一个非常糟糕的主意：

1. 调用 System.gc() 的成本很高，特别是因为（如果它做了什么）可能会触发完整的垃圾收集。这将导致堆中每个可访问对象中的每个引用都被跟踪。

2. 如果您阅读了 System.gc() 的 javadocs，您会发现它只是 JVM 运行 GC 的“提示”。 JVM 可以随意忽略提示...这将我们带到下一个问题。

3. 如果您不显式运行 GC，则 GC 运行可能需要很长时间。即使这样，也不能保证终结器会立即运行。

同时：

• 所有打开的文件保持打开状态，可能会阻止其他应用程序使用它们，
• 流中任何未写入的数据都保持未写入状态，
• 您的 java 应用程序甚至可能会遇到打开其他流导致文件描述符槽耗尽的问题。

依赖终结来处理输出流还有最后一个问题。如果流最终确定时存在未刷新的数据，则输出流类将尝试刷新它。但这一切都发生在 JVM 内部线程上，而不是应用程序的线程之一上。因此，如果刷新失败（例如，因为文件系统已满），您的应用程序将无法捕获所产生的异常，因此无法报告它......或执行任何恢复操作。

编辑

回到原来的问题，事实证明 BufferedOutputStream 类不会重写默认的 Object.finalize() 方法。因此，这意味着 BufferedOutputStrean 在被垃圾回收时根本不会被刷新。缓冲区中任何未写入的数据都将丢失。

这是明确关闭流的另一个原因。事实上，在这种特殊情况下，调用 System.gc() 不仅是不好的做法，而且是错误的做法。它还可能导致数据丢失。