Hung Threads java.lang.ClassLoader.findBootstrapClass

Question

Meine J2EE-Anwendung läuft langsam. Wir haben die Thead Dumps während dieser Situation genommen und festgestellt, dass der folgende Thread in mehreren Dumps lauffähig war und Sperren auf einigen Monitoren genommen hat, die dazu führen, dass andere Threads (direkt oder indirekt) auf die Sperren warten.

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) 
.....

Können Sie bitte vorschlagen, warum dieser Thread sich nicht bewegt und andere Threads funktionieren lassen?

Answer 1

Warum lädt Ihre Anwendung so viele Klassen (die Sperren sind in der loadClass)? Es wird erwartet, dass Ihre App nur während der Initialisierung und der Aufwärmphase ungeladene Klassen lädt.

Ich vermute also, dass einer der folgenden Punkte zutrifft:

• Sie erstellen eine Menge verschiedener dynamischer Proxy-Klassen, anstatt zu versuchen, sie wiederzuverwenden.
• Sie erstellen unnötig viele ClassLoader oder verwenden sie zumindest falsch.
• Sie starten und beenden mehrere parallele JVMs.

Unnötig zu sagen, dass alle diese Dinge sehr teuer sind und so weit wie möglich vermieden werden sollten.

Answer 2

Wenn dieses Thema pausiert wird auf unbestimmte Zeit Ich würde vermuten, dass es sich um einen zirkulären Verweis irgendeiner Art handelt (Symlinks? andere?).

Wenn Sie die Protokollierung für geladene Klassen aktivieren, können Sie vielleicht mehr herausfinden.

java -verbose:class your.Class

Dies könnte Ihnen eine Menge zeigen; ich glaube, es schreibt in system.out, also müssen Sie im entsprechenden Protokoll nachsehen.

Answer 3

Ich habe diese Art von Dingen in OSGI gesehen, wo die Classloader-Struktur ein Graph ist und nicht ein Baum wie in J2EE üblich. Classloader sperren sich selbst, wenn sie eine Klasse laden, so dass zwei Threads (a, b), die Klassen von Classloadern in der Reihenfolge (x, y) bzw. (y, x) laden, sich blockieren können. Dies kann passieren, wenn statische Initialisierungen das Laden weiterer Klassen von dem anderen Classloader verursachen. Es kommt nicht häufig vor, dass die Bootstrap-Klassen das Laden von Klassen aus dem App-Classloader verursachen, aber alle Fabrikklassen in Standardbibliotheken, die den Thread-Context-Loader verwenden, würden in diese Kategorie fallen. Die übliche Lösung besteht darin, die Klassen zu einem früheren Zeitpunkt zu laden, vielleicht während des Starts der Anwendung, um den Zyklus zu unterbrechen.