コードベースにファイルハンドルやストリームが正しく閉じられていないという問題があります。私たちは最終的に非常に重い負荷の下でTooManyOpenFiles例外を取得します。 lsofの出力に基づいて、私たちはロッキングシステムがどこにあるのかを知っていると確信していますが、私の質問は、リソースが正しく閉じられたことをチェックするユニットテストを書くにはどうすればいいですか？現在開いているファイルの数を調べるためにJREに問い合わせる方法はありますか？どういうわけかファイル操作を傍受して監視することはできますか？ファイルを適切に閉じていることを確認するJavaユニットテストの良いパターンは何ですか？
すべてのファイルI/Oを管理し、参照を数え、それらが閉じられていることを確認するためにコードを計測する必要があると思われますが、誰かがトップダウンソリューションを知っていれば上記のアイデアは、大きな助けになるでしょう！
Testsについて話しているので、PowerMock http://code.google.com/p/powermock/がこのトリックを行う可能性があります。私が間違っていない場合、静的メソッドとコンストラクタをモックすることが可能になります。だから、コンストラクタやクローズメソッド、あるいはリソースを解放するために必要なものを模擬したり、スパイしたりすることができます。
私は私のテストでそれを避けようとしますが、それはあなたが面倒な価値があるかもしれないとあなたが記述した場合。
私はこの答えを正しいものとしてマークしています。なぜなら、それは私が探していたものに最も近いからですが、私の場合は最後に単体テストを書くことはしませんでした。 lsofを使用して、私のパッチの前にファイルが閉じられていないことを確認し、その後閉鎖していました。 –
AspectJのようなアスペクト指向プログラミング（AOP）ツールを使用して、開いている/閉じているファイルを数えるコードをFileInputStreamとFileOutputStreamに追加できます。これはかなり簡単です（詳細はツールに依存します）。堅牢で非侵襲的です。
AspectJは、非侵襲的なビルドチェーンの変更を検討するときだけ非侵襲的だと思います。 –
これは、AspectJを使ったテストビルドのためのもので、テストのセットアップの一部です。 –
はい - これはかなり低レベルのライブラリコードに追加したいと思う以上のものです。 –
これはJMX経由で見ることができます。あなたがまだの場合は、あなたのJVMにJMXを有効にする必要があります http://java-monitor.com/forum/showthread.php?t=130
：
誰かがここにコードを掲載しました。
良い操作方法のように聞こえますが、単体テストとしてはうまくいかないと思います。 –
私はJavaがバックグラウンドでそれをすべて実行していると信じています。うーん、多分私はそれを見逃しているかもしれません。 – Coffee
Javaは最終的にあなたの開いているファイルをガベージコレクションして閉じますが、リソースを非常に迅速に開いて捨てると、それは追いつかなくなります。ハンドルを明示的に閉じる方がはるかに優れています。 –