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 の親クラスローダーを知る方法はありますか?
どんな助けにも感謝します。