Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination.
# 1 楼答案
通过jsut将引用设置为
null，您不会释放底层文件句柄。这意味着您需要依靠垃圾收集器和终结来完成这项工作，这很可能会导致运行时错误，因为如果终结无法跟上，操作系统将耗尽文件句柄。此外，还无法确定写入流的内容何时进入磁盘# 2 楼答案
可能是的，不过这取决于流（最终）连接到什么
另一个问题是它是否重要。这也取决于
如果流在输出管道中包含缓冲区，则分配
null而不是关闭可能会导致缓冲数据丢失如果您反复这样做，泄漏的资源可能会堆积起来，最终导致应用程序失败，因为它已经用完了“文件描述符”
另一方面，如果您缓慢地泄漏资源，，则流可能会在“文件描述符”不足位出现之前被垃圾收集并最终确定。（该
finalize()方法调用close()…）但无论哪种方式，调用
close()都是最佳实践。。。并通过使用“try/finally”或“try with resources”确保关闭始终。分配null而不是调用close()是自找麻烦# 3 楼答案
如果不知道outputStream的实现，很难回答您的问题。但是请记住，当您将一个变量设置为null时，您并没有删除该变量最初指向的对象。将某些变量设置为NULL并不等同于调用C++中的删除，或者Objto-C中的释放。没有自动调用的清理代码。这正是close（）首先存在的原因。您可以假设，既然它存在，它就可以被用来做它所说的事情——清理资源
简言之，答案是肯定的，这可能会泄漏资源。调用要为清理而调用的方法
# 4 楼答案
始终
close您的流Stream不仅是堆上的普通对象，就像普通javaobject，它还处理底层操作系统的编写如果您使用引用
null，则不会发生刷新参见关闭的文档
那么，如果简单地将
reference简化为null，那么上面的过程会怎么样呢您的问题不会从jdk7中提出
如果您使用的是java7，即The try-with-resources Statement，那么您永远不必显式地关闭流