WebSphere Web Container Threads mit maximalen Thread-Status in runnable

Question

Wir haben WebSphere-Umgebung mit 2 Knoten-Agenten und 4 Application Server. Bei hohem Datenaufkommen reagiert einer der Anwendungsserver nicht mehr auf Anforderungen, da er auf die maximale Threadanzahl des Web-Containers springt.
Beim Analysieren des Thread-Dumps haben wir festgestellt, dass sich ca. 60% der Threads im Runnable-Zustand befinden und jeweils 20% des Status Wait und Parked aufweisen.
Wir sehen keine Deadlock-Warnung im Thread-Dump. Auf genaues Hinsehen haben wir festgestellt, dass eine des Web-Container-Thread die Sperre mit folgenden Meldung besitzt:

Owns Monitor Lock on com/ibm/ws/classloader/ExtJarClassLoader@0x0A00000000FA6F30 

Könnte jemand mit dem Verständnis der oben genannten Fehler helfen und seiner Auflösung?

Answer 1

Es ist wichtig, sich die Stack-Ablaufverfolgung des Threads anzusehen, der die Sperre besitzt, und dann die Stack-Ablaufverfolgung aller anderen Threads zu betrachten, die auf diese Sperre warten. Für ExtJarClassLoader bedeutet das fast sicher, dass alle Threads versuchen, loadClass-Operationen durchzuführen. Wenn viele Threads dies versuchen und blockiert werden, bedeutet dies normalerweise, dass der Ausführungscode eine fehlgeschlagene loadClass-Operation versucht, die ClassNotFoundException abfängt und fortfährt. Das Erstellen und Werfen von ClassNotFoundException ist teuer, daher sollte der Code normalerweise so geändert werden, dass das Gesamtergebnis zwischengespeichert wird (z. B. wenn eine Sequenz von Klassenladevorgängen versucht wird, sollte das positive/negative Ergebnis irgendwie zwischengespeichert werden). Dies wird natürlich kompliziert, wenn der Code, der loadClass aufruft, eine Bibliothek eines Dritten ist.