java - 我的 java 进程的文件描述符变为 "bad"，我不知道为什么

Question

我有一个用 Lucene 构建的 java webapp，我不断收到各种“文件已经关闭”的异常——这取决于我使用的目录实现。我已经能够从 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 个请求/秒，然后大约 10% 的请求开始从它们下面关闭它们的文件描述符，中间请求(代码检查有效的 IndexReader 对象和在处理请求的开始创建一个)。一旦达到大约 3 个请求/秒，所有请求都会开始失败，文件描述符错误。

我最好的猜测是不知何故在操作系统级别存在资源匮乏并且操作系统正在清理 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