唯一の現実的なオプションは、(残念ながら) JVM をできるだけ早く終了することです。
おそらく、すべてのコードを変更してエラーをキャッチして応答することはできないためです。 OnOutOfMemoryError
を信頼しない場合 (Java 8 で使用され、Windows で動作する vfork を使用すべきではないのはなぜかと思います)、少なくともヒープダンプをトリガーして、これらのファイルを外部から監視できます:
java .... -XX:+HeapDumpOnOutOfMemoryError "-XX:OnOutOfMemoryError=kill %p"
かなり長い間これを試した後、これが私たちにとってうまくいった解決策です:
<オール>OutOfMemoryError
をキャッチします。 すぐに終了し、メモリ不足状態を終了コードでコントローラ JVM に通知します。Runtime
の消費メモリ量を定期的に確認します。 .メモリの使用量が限界に近づいたら、コントローラ JVM にメモリ不足の状態を通知するフラグ ファイルを作成します。この状態から回復して正常に終了する場合は、終了する前にそのファイルを削除してください。hs_err_pidXXX.log
存在し、「メモリ不足エラー」という行が含まれています。 (このファイルは、クラッシュした場合に備えて Java によって生成されます。)これらのチェックをすべて実装して初めて、フォークされた JVM がメモリ不足になるすべてのケースを処理できるようになりました。それ以来、これが起こったケースを見逃すことはないと信じています.
Java フラグ -XX:OnOutOfMemoryError
フォークの問題のため使用されず、-XX:+HeapDumpOnOutOfMemoryError
ヒープ ダンプが必要以上であるため、使用されませんでした。
このソリューションは、確かにこれまでに書かれたコードの中で最も洗練されたものではありませんが、私たちのために仕事をしてくれました.