我正在尝试写入多个文件,确切地说是19.写了几百次之后,我得到了Java IOException:打开的文件太多了.但是,就像我说的那样,我打开了19个文件,并且我在开始时打开了所有文件.这里有什么问题?我可以验证写入是否成功.
编辑:我没有使用try-catch-finally块.我让函数抛出异常.现在我把try-catch-finally放在他们周围,他们似乎做得更好.
大多数人都是对的,因为我打开的文件超出了我的想象.还在跟踪事情.稍后我会发布更新.
重新编辑:确保所有文件访问都用try-catch包装 - 最终修复了问题.谢谢
Ste*_*n C 56
在Linux和其他类似UNIX/UNIX的平台上,操作系统限制进程在任何给定时间可能具有的打开文件描述符的数量.在过去,这个限制曾经是硬连线1,而且相对较小.这些天它更大(数百/数千),并受到"软"每进程可配置资源限制的约束.(查看ulimit内置的shell ...)
您的Java应用程序必须超过每进程文件描述符限制.
你说你有19个文件打开,几百次之后你会得到一个IOException,说"打开的文件太多了".现在,只有在请求新文件描述符时才会发生此特殊异常; 即打开文件(或管道或套接字)时.您可以通过打印IOtraception的堆栈跟踪来验证这一点.
除非您的应用程序以小资源限制运行(这似乎不太可能),否则它必须重复打开文件/套接字/管道,并且无法关闭它们.找出为什么会发生这种情况,你应该能够弄清楚该怎么做.
仅供参考,以下模式是一种安全的写入文件的方法,保证不会泄漏文件描述符.
Writer w = new FileWriter(...);
try {
// write stuff to the file
} finally {
try {
w.close();
} catch (IOException ex) {
// Log error writing file and bail out.
}
}
Run Code Online (Sandbox Code Playgroud)
1 - 硬连线,如编译到内核中.更改可用fd插槽的数量需要重新编译...并且可能导致更少的内存可用于其他事情.在Unix通常在16位机器上运行的时代,这些事情确实很重要.
UPDATE
Java 7的方式更简洁:
try (Writer w = new FileWriter(...)) {
// write stuff to the file
} // the `w` resource is automatically closed
Run Code Online (Sandbox Code Playgroud)
更新2
显然,在尝试运行外部程序时,您还会遇到"打开的文件太多".基本原因如上所述.但是,您遇到此问题的原因exec(...)是JVM正在尝试创建将连接到外部应用程序的标准输入/输出/错误的"管道"文件描述符.
对于 UNIX:
正如 Stephen C 所建议的,将最大文件描述符值更改为更高的值可以避免此问题。
尝试查看您当前的文件描述符容量:
$ ulimit -n
Run Code Online (Sandbox Code Playgroud)
然后根据您的要求更改限制。
$ ulimit -n <value>
Run Code Online (Sandbox Code Playgroud)
请注意,这只会更改当前 shell 和任何子/后代进程中的限制。要使更改“坚持”,您需要将其放入相关的 shell 脚本或初始化文件中。