オープンファイルのエラーが多すぎます。java.io.FileNotFoundException

Question

私のプログラムでは、たくさんのファイルをスキャンしてその内容を読み取るループがあります。問題は、（（）私がまたは理解）約1500のファイルの反復の上に起こって再生することができないよう

問題：このメソッドへ

java.io.FileNotFoundException: /path/to/file//myFile (Too many open files) 

例外ポイント：

private static String readFileAsRawString(File f) throws IOException { 

    FileInputStream stream = new FileInputStream(f); // <------------Stacktrace 
    try{ 
     FileChannel fc = stream.getChannel(); 
     MappedByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0, fc.size()); 

     return Charset.defaultCharset().decode(bb).toString(); 
    } finally { 
     stream.close(); 
    } 
} 

QAで20,000件以上のファイルを処理していましたが、問題はないようです。

上記の貼り付けたコードに問題があると思われますか？

Answer 1

マッピングは疑わしいです。 MappedByteBufferは、そのFileChannelより長く存続する可能性があり、ガベージコレクトされるまで有効です。 GCを実行するのに十分なゴミがないかもしれませんが、おそらく特定のプラットフォームのファイルハンドルは参照されていないバッファによって保持されます。明示的なガベージコレクションが無効になっていない限り

---

（-XX:-DisableExplicitGC）、あなたは、例外をキャッチSystem.gc()を呼び出し、再度試みることによってこれをテストすることができるはずです。それが2回目の試行で動作するなら、それはあなたの問題です。しかし、恒久的な修正としてSystem.gc()を呼び出すことは悪い考えです。全体的に最高のパフォーマンスを発揮するソリューションは、ターゲットプラットフォームでいくつかのプロファイリングを行います。

Answer 2

私は速すぎるファイルを開くと、これをテストするためにwait（）を追加しようとします。 次に、オープンファイルのトラックを保持するスタティックカウンタを追加し、多数のファイルが既に開いている場合は、待機メカニズムを追加します。

Answer 3

この簡単なタスクにはMappedByteBufferを使用しないでください。それらが解放される明確な時間はありません。ファイルを開いて読み、閉じてください。