ハングしたスレッドjava.lang.ClassLoader.findBootstrapClass

Question

J2EEアプリケーションのパフォーマンスが低下しています。私たちはその状況でThead Dumpsをとり、次のスレッドが複数のダンプでRunnableであり、他のスレッドが（直接的または間接的に）ロックを待っているいくつかのモニターをロックしていることがわかりました。

at java.lang.ClassLoader.findBootstrapClass(Native Method) 
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:301) 
    - locked [0x9747c360] (a sun.misc.Launcher$ExtClassLoader) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:299) 
    - locked [0x9747c318] (a sun.misc.Launcher$AppClassLoader) 
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) 
    - locked [0x9747c318] (a sun.misc.Launcher$AppClassLoader) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:251) 
..... 

このスレッドは動いておらず、他のスレッドを動作させることができますか？

Answer 1

あなたのアプリは非常に多くのクラスをロードしています（ロックはloadClassにあります）。あなたのアプリは、初期化とウォームアップの間だけアンロードされたクラスをロードすることが期待されます。

• は、あなたが代わりにそれらを再利用しようとしているの異なるダイナミックプロキシクラスの多くを作成している：

  だから、私は、次のいずれかが起こっていると思われます。

• 不必要に多くのClassLoaderを作成しているか、少なくともそれらを悪用しています。
• 複数の並列JVMを開始して終了しています。

これらのことはいずれも非常に高価であり、可能な限り避けなければならないことは言うまでもない。

Answer 2

このスレッドが一時停止されている場合無期限に私は、ある種の循環参照（symlinks？other？）を推測します。

ロードされたクラスのロギングを有効にすると、詳細を調べることができます。

java -verbose:class your.Class 

これはあなたに多くのことを示すかもしれません。私はsystem.outに書き込むと思うので、適切なログをチェックインする必要があります。

Answer 3

OSGIでは、このようなことが起こりました。クラスローダー構造は、通常のJ2EEと同じようにツリーではなくグラフです。クラスローダーはクラスをロードするときにロックされるため、（x、y）および（y、x）の順でクラスローダーからクラスをロードする2つのスレッド（a、b）がそれぞれデッドロックする可能性があります。これは、静的初期化子が他のクラスローダーからより多くのクラスローディングを引き起こす場合に発生します。ブートストラップクラスがアプリケーションクラスローダーからのクラスローディングを引き起こすことは頻繁ではありませんが、スレッドコンテキストローダーを使用する標準ライブラリのファクトリクラスはすべてこの請求書に適合します。通常の解決策は、アプリの起動時にクラスを先に読み込むことです。そのため、サイクルが壊れます。