我的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