Java IOException“打开的文件太多”

Question

我使用多个文件来执行一些文件I / O（写入19个文件，确实如此）。写他们几百次后，我得到了Java IOException：Too many open files。但是实际上我一次只能打开几个文件。这里有什么问题？我可以验证写入是否成功。

Answer 1

在Linux和其他UNIX /类似UNIX的平台上，操作系统对进程在任何给定时间可能具有的打开文件描述符的数量进行了限制。在过去，此限制曾经是硬接线1，并且相对较小。如今，它要大得多（几百/几千），并且受“软”每进程可配置资源限制。（查找ulimit内置的shell ...）

您的Java应用程序必须超出每个进程的文件描述符限制。

您说打开了19个文件，几百次之后，您得到一个IOException消息，说“打开的文件太多”。现在，仅当请求新的文件描述符时，才可能发生这种特殊的异常。即，当您打开文件（或管道或插座）时。您可以通过打印IOException的堆栈跟踪来验证这一点。

除非您的应用程序以很小的资源限制运行（这似乎不太可能），否则必须重复打开文件/套接字/管道，然后无法关闭它们。找出发生这种情况的原因，您应该能够弄清楚该怎么做。

仅供参考，以下模式是一种写入文件的安全方法，可以保证不会泄漏文件描述符。

Writer w = new FileWriter(...);

try {

    // write stuff to the file

} finally {

    try {

        w.close();

    } catch (IOException ex) {

        // Log error writing file and bail out.

    }

}

1-硬接线，如编译到内核中一样。更改可用fd插槽的数量需要重新编译...并可能导致更少的内存可用于其他用途。在Unix通常在16位计算机上运行的时代，这些事情确实很重要。

更新

Java 7的方式更加简洁：

try (Writer w = new FileWriter(...)) {

    // write stuff to the file

} // the `w` resource is automatically closed 

更新2

显然，您在尝试运行外部程序时也会遇到“文件打开过多”的情况。基本原因如上所述。但是，遇到这种情况的原因exec(...)是JVM试图创建“管道”文件描述符，该描述符将连接到外部应用程序的标准输入/输出/错误。

Answer 2

尽管在大多数情况下，错误非常明显，即文件句柄尚未关闭，但我只是在Linux上遇到了JDK7实例，可以很好地说明这一点。

该程序打开了FileOutputStream（fos），BufferedOutputStream（bos）和DataOutputStream（dos）。写入数据输出流后，dos已关闭，我认为一切都很好。

但是在内部，dos尝试刷新bos，这返回了Disk Full错误。该异常被DataOutputStream吞噬，结果底层的Bos没有关闭，因此fos仍然打开。

在稍后的阶段，该文件便从（带有.tmp的文件）重命名为其真实名称。因此，java文件描述符跟踪器丢失了对原始.tmp的跟踪，但它仍然处于打开状态！

为了解决这个问题，我必须首先自己刷新DataOutputStream，检索IOException，然后自己关闭FileOutputStream。

我希望这可以帮助别人。

Answer 3

对于UNIX：

正如Stephen C所建议的，将最大文件描述符值更改为更高的值可以避免此问题。

尝试查看您当前的文件描述符容量：

   $ ulimit -n

然后根据您的要求更改限制。

   $ ulimit -n <value>

请注意，这只会更改当前shell和任何子进程/子进程的限制。要使更改“坚持”，您需要将其放入相关的Shell脚本或初始化文件中。