为什么关闭（）输入流是好的？ [英] Why is it good to close() an inputstream?

问题描述

我在Java编程语言方面有丰富的经验。但是我一直想到的一件事是，为什么有必要 close（） java.io.InputStream 或其子类？

I have a sound experience in Java programming language. But one thing that has always been in my mind is that why is it necessary to close() java.io.InputStream or its subclasses?

现在使用 java.io.OutputStream ，比如说 FileOutputStream ，写入文件后，如果我们没有 close（）输出流，我们打算在文件中写入的数据仍保留在缓冲区中，而不是写入文件。

Now with java.io.OutputStream, say FileOutputStream, after writing to a file, if we don't close() the output stream, the data that we intended to write in the file remains in the buffer and is not written to the file.

所以有必要 close（）一个 OutputStream 。但是，在未关闭 InputStream 之后，我从未有过任何痛苦的经历。

So it becomes necessary to close() an OutputStream. But i never had any bitter experiences after not closing an InputStream.

但是，互联网和书籍上的所有文章仍然表示关闭任何流总是好的可能是 InputStream 或 OutputStream 。

But still all articles on the internet and books say that it is always good to close any Stream may it be an InputStream or an OutputStream.

所以我的问题是为什么有必要 close（）一个 InputStream ？人们说你可能面临内存泄漏，你不要 close（）它。那么什么样的内存泄漏呢？

So my question is that why does it become necessary to close() an InputStream? People say that you may face a memory leak of you don't close() it. So what kind of a memory leak is that?

推荐答案

一个InputStream占用了一个微小的内核资源，一个低级文件句柄。此外，只要您打开文件进行读取，该文件将在某种程度上被锁定（从删除，重命名）。让我们想象你不关心锁定的文件。最后，如果您需要读取另一个文件，并使用新的InputStream打开它，内核会依次为您分配一个新的描述符（文件流）。这将加起来。

An InputStream ties up a tiny kernel resource, a low level file handle. In addition, the file will be locked to some extent (from delete, renaming), as long as you have it open for read. Lets imagine you didn't care about the locked file. Eventually, if you need to read another file, and open it with a new InputStream, the kernel sequentially allocates a new descriptor (file stream) for you. This will add up.

长时间运行应用程序的程序失败只是时间问题。

It is just a matter of time until program failure for a long running application.

处理器的文件描述符表大小有限。最终，文件句柄表将耗尽进程的空闲插槽。即使成千上万，你仍然可以在长时间运行的应用程序中轻松耗尽，此时，你的程序无法再打开新的文件或套接字。

The file descriptor table for a processor is of limited size. Eventually the file handle table will run out of free slots for the process. Even in the thousands, you can still easily exhaust this for a long running application, at which point, your program can no longer open a new file or socket.

这个过程文件描述符表与以下内容一样简单：

The process file descriptor table is as simplistic as something like:

IOHANDLE fds[2048];  // varies based on runtime, IO library, etc.

首先占用3个插槽。填写，你已经对自己进行了拒绝服务。

You start with 3 slots occupied. Fill that up and you have performed a denial of service on yourself.

所以很高兴知道;如何最好地应用它？

So all thats nice to know; how best to apply it?

如果您依赖本地对象超出范围，那么它可以直接使用垃圾收集器，它可以在自己的甜蜜时间内收获它（不确定性）。所以不要依赖GC，明确地关闭它们。

If you rely on local objects to go out of scope, then its up to the Garbage Collector, which can reap it in its own sweet time (nondeterministic). So don't rely on the GC, close them explicitly.

使用Java，你想在实现java.lang.AutoCloseable的类型上使用try-with-resources， 每个文档都包含实现java.io.Closeable的所有对象： https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

With Java, you want to use try-with-resources on types that implement java.lang.AutoCloseable, "which includes all objects which implement java.io.Closeable" per the docs: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

使用C＃，相当于使用阻止实现IDisposable的对象

With C#, the equivalent is a "using" block on objects that implement IDisposable

这篇关于为什么关闭（）输入流是好的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！