java最大文件描述符,我的java进程的文件描述符“坏”,我不知道为什么

我有一个使用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个reqs / sec,所有的请求开始失败与坏的文件描述符.

我最好的猜测是,在某种程度上,在操作系统级别的资源匮乏,操作系统正在清理fds …但这只是因为我已经消除了我所拥有的所有其他想法.我已经检查了ulimits和filesystem fd限制,并且打开的描述符的数量远低于任一限制(例如从sysctl fs.file-nr：1020 0 203404,ulimit -n：10240输出).

我几乎完全不需要测试,我没有比我发现的那一天更接近解决这个问题.有没有人经历过类似的事情？

编辑07/12/2011：我发现一个OSX机器用于一些测试,并确认这是在OSX上发生的.我也在物理Linux盒子上进行了测试,并复制了这个问题,所以我无法复制此问题的唯一操作系统是Windows.我猜这与POSIX处理文件描述符有关,因为这似乎是两个测试系统(JDK版本,tomcat版本和webapp在所有平台上都是相同的)之间唯一的相关差异.