Hung Threads java.lang.ClassLoader.findBootstrapClass

My J2EE application is slow. We took Thead Dumps during this situation and found that the next thread was Runnable in several dumps and made locks on some monitors that cause other threads (directly or indirectly) to wait for locks.

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

Could you suggest which of these threads is not moving and allow other threads?

+3
source share
3 answers

Why does your application load so many classes (locks are in loadClass)? It is expected that your application will load the unloaded classes only during initialization and warming up.

So, I suspect one of the following things is happening:

  • - , .
  • ClassLoaders , , .
  • JVM.

, , .

+1

, OSGI, classloader , , J2EE. Classloaders , (a, b), (x, y) (y, x), , . , . , bootstrap , factory , , . , , , , , .

+1

, , - (symlinks? other?).

, .

java -verbose:class your.Class

It can show you a lot; I believe that he writes system.out, so you will need to check the corresponding log.

0
source

Source: https://habr.com/ru/post/1786363/


All Articles