を使用しているlibrary codeがあります。私のアプリケーションでは、このコードが多く呼ばれているので、メモリは、DeleteOnExitHookに積もっています。これにより、ヒープが無期限に成長し、最終的にはOutOfMemoryErrorsが発生します。クラスが完全にパッケージ保護されているので、削除対象のファイルを中間的に削除する簡単なメカニズムがあります。反射マジックでこのリストを空にすることはできますか？File.deleteOnExitで削除待ちのファイルをクリーンアップ
私が理解しているように、汚れたハックが必要なので、これで十分です。 filesのフィールド値を復元する必要があります。これにより、通常のシャットダウン（または次にこのハックを使用するとき）がうまく動作するようになります。
注：他のライブラリによってスケジュールされたファイルを含むすべてのファイルが削除されます。あなたのケースでそれが安全であることを確認してください。
またjava.lang.reflect.Method run = Class.forName ("java.io.DeleteOnExitHook").getDeclaredMethod ("runHooks");
java.lang.reflect.Field files = Class.forName ("java.io.DeleteOnExitHook").getDeclaredField ("files");
run.setAccessible (true);
files.setAccessible (true);
run.invoke (null);
files.set (null, new java.util.LinkedHashSet <String>());
、ちょうど
files.get (null)
でスケジュールファイルを取得するには、あなたが行くようにもセットから名前を削除、セットを反復処理し、手動でファイルを削除します。この方法で、あなたは自分自身を削除するファイルを決定することができます。
ビットを読み込んだ後、 'deleteOnExit（）'は非常に奇妙で部分的に危険な方法のようです。これは '' System.exit（0） ''のような "正常終了"で削除するファイルの文字列だけを格納します。ハード・パワー・オフや 'kill 'や' System.exit（1） 'のような他の終了とともに、ファイルは削除されません。ですから、私は必ず 'deleteOnExit（）'の使用を避けようとします。使用したライブラリを別のライブラリに置き換えることはできますか？実際には、反射を使用して可視性を変更し、メソッドを単純な 'delete'で上書きすることができます。 – Korashen
Alternativly、ほとんどの好きではあまり便利ではなく、ライブラリをフォークし、そのコードを書き直して、自分で構築してください。 （そしておそらくプルリクエストを作成するのでしょうか？） – Korashen
私はそこにパッチを提出しても構いませんが、おそらくそれが合併するまでに時間がかかるでしょう。 –