問題タブ [metaspace]

springboot マイクロサービスのメタスペースが拡大し続けている状況がありますが、ヒープは正常に動作しています。

jmap -clstats は、次の種類の死んだクラスローダーが何千もあることを示しています。

0x00000000e3c8e3c8 1 4087 0x00000000e0004d18 デッド com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl$TransletClassLoader@0x000000010087c7e8

最初のハイ ウォーターマークで GC がトリガーされ、メタスペースの低下が見られます。定義されたメタスペース サイズが原因でトリガーされるこの強制 GC の後、メタスペースが継続的に成長し、同じ種類のデッド クラスローダーがメタスペースに保持されていることがわかります。少しの GC アクティビティが見られますが、メタスペースの消費量は減少していません。ただし、visualvm を使用して GC コレクションを強制すると、大量のクラスがアンロードされ、メタスペースの消費がサービス開始時の状態に戻ります。

JVM 管理の GC がこれらの死んだクラスローダーをアンロードしないのに、強制 GC がアンロードするのはなぜですか? 弱い/ソフト/ファントム参照が理由である場合、それは強制GCにも適用されるべきではありませんか?

これはJava8です。次にどこを見るべきかについて、誰かがいくつかの指針を与えることができますか? 明らかにリークがあるので、TemplatesImpl$TransletClassLoader の親クラスローダーを知る方法はありますか?

どんな助けにも感謝します。

ミートスペースの oom で問題が発生しました。ロードされている正確なクラスを取得する方法はありますか? -verbose:class を使用してログを出力しましたが、「[Loaded sun.reflect.GeneratedMethodAccessor9668 from JVM_DefineClass]」と表示され、元のクラスが何であるかはよくわかりません。「jmap -clstats pid」を使用しようとしていますが、これはプロ環境で長時間停止し、クラスローダーのサイズしか取得できず、正確なクラスがロードされているかわかりません。「async-profiler」を使用して原因を突き止めようとしましたが、うまくいきません (おそらく私の間違った使い方が原因です)。メタスペースにロードされたクラスを知るためのツールまたはコマンドはありますか?

jdk1.8以降で、MetaspaceTestクラスをjvmにロードする際のメモリレイアウトについての私の理解ですが、そうでしょうか?