我的java进程的文件描述符变得“糟糕”，我不知道为什么

Question

我有一个使用Lucene构建的java webapp，我不断获得各种“文件已经关闭”的异常 - 取决于我使用的Directory实现。 我已经能够从Lucene中获取“java.io.IOException Bad File Descriptor”和“java.nio.channels.ClosedChannelException”，通常包含在IndexReader的AlreadyClosedException周围。

有趣的是，我还没有关闭IndexReader，似乎文件描述符本身就是陈旧的。 我正在使用最新版本的Lucene 3.0（没有时间升级3.0系列），最新版本的Oracle JDK6，最新版本的Tomcat 6和最新版本的CentOS。 我可以在其他Linux系统上使用相同的软件复制该错误，但不能在Windows系统上复制该错误，并且我没有要测试的OSX PC。 Linux服务器使用qEmu进行虚拟化，如果这可能很重要的话。

这似乎也与负载有关 - 这种情况发生的频率与Tomcat服务的请求数/秒（对于这个特定的webapp）相对应。 例如，在一台服务器上，每个请求按预期完成，直到它必须处理~2 reqs / sec，然后大约10％开始让它们的文件描述符从它们下面关闭，mid-request（代码检查有效的IndexReader对象和在处理请求的开始处创建一个）。 一旦达到大约3 reqs / sec，所有请求都会以错误的文件描述符开始失败。

我最好的猜测是，某种程度上在操作系统级别存在资源匮乏，操作系统正在清理fds ......但这仅仅是因为我已经消除了我所拥有的所有其他想法。 我已经检查了ulimits和文件系统fd限制以及开放描述符的数量远低于任一限制（示例输出来自sysctl fs.file-nr ：1020 0 203404，ulimit -n：10240）。

我几乎完全没有要测试的东西了，而且我发现这个问题的时间比我发现它的日子还要近。 有没有人经历过类似的事？

编辑07/12/2011：我发现了一台用于某些测试的OSX机器，并确认这种情况发生在OSX上。 我还在物理Linux机器上进行了测试并复制了这个问题，因此我唯一无法复制此问题的操作系统是Windows。 我猜这与POSIX处理文件描述符有关，因为这似乎是两个测试系统之间唯一的相关区别（JDK版本，tomcat版本和webapp在所有平台上都是相同的）。

Answer 1

您可能在Windows上看不到这种情况的原因可能是它的FSDirectory.open默认使用SimpleFSDirectory。

查看FSDirectory和NIOFSDirectory顶部的警告：红色文本http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/store/NIOFSDirectory.html ：

注意：如果在线程被IO阻塞的同时，在线程中断时直接或间接从线程访问此类可以立即关闭基础文件描述符。 文件描述符将保持关闭状态，随后对NIOFSDirectory的访问将引发ClosedChannelException。 如果您的应用程序使用Thread.interrupt（）或Future.cancel（boolean），您应该使用SimpleFSDirectory来支持NIOFSDirectory

https://issues.apache.org/jira/browse/LUCENE-2239