私のプロセスでは、新しい Thread オブジェクト (実際には Thread のサブクラス) を継続的に作成し (1 秒あたり最大数まで)、それを実行して正常に終了します。
たとえば、プロセスが 25 日間稼働している場合、プロセスは hprof を残して終了する可能性があることに気付きました。これは OOM を意味します。しかし、ヒープ ダンプは、ヒープに割り当てられたメモリに比べて小さいため、おそらく PermGen OOM であり、原因を突き止めようとしています。
-XX:+HeapDumpOnOutOfMemoryError を禁止する特別な jvm パラメータは使用していません。
私は閉鎖をもたらすためにこれに答えています。多くの調査の後、少なくとも私の場合、非常に多数のスレッドの作成はOOMの原因ではありませんでした。
私は2つの方法でそれを除外しました：
この問題は別のいくつかのインスタンスで報告されており、それらのケースでは多くのスレッドが生成されていませんでした。
250万を超えるスレッドを生成し（この場合は通常の作業を実行）、OOMの問題が発生しないテストを作成しました。
したがって、作成されたスレッドの数が非常に多いことは問題ではありません。
これが perm gen の問題であると仮定するのではなく、jhatを使用してダンプ ハットが生成されていることを確認してみましたか? hrof ファイルのサイズとダンプされるヒープのサイズの間に直接的な相関関係があるかどうかはわかりません。
あなたのヒープ ダンプは確かに PermGen の使用法を教えてくれるはずです -- 見ましたか?
とにかく、クラスをロードするクラスローダーが GCd である場合、ロードされたクラスも GCd です。通常、これがクラスをアンロードする唯一の方法です。アプリケーション レベルのクラス ローダーを使用し、定期的に破棄することを検討する必要があります。これにより、メモリの問題を防ぐことができます。