Analyse von festsitzenden Threads auf einer nativen Methode

Question

Ich benutze tomcat und java 1.7.0_80. Das Produkt ist eine Regel-Engine, die Drools verwendet. Ich habe eine Verlangsamung nach dem Laden des Systems. Ich habe einen Thread-Dump und viele Threads sehen, die wie folgt aussehen:

http-bio-9980-exec-48" daemon prio=10 tid=0x00007fa8b43a3000 nid=0x10299    runnable [0x00007fa9522c5000] 
java.lang.Thread.State: RUNNABLE 
    at java.lang.Class.getDeclaredConstructors0(Native Method) 
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2595) 
    at java.lang.Class.getConstructor0(Class.java:2895) 
    at java.lang.Class.newInstance(Class.java:354) 
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399) 
    at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395) 
    at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:77) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:46) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
    at java.lang.reflect.Method.invoke(Method.java:606) 
. 
. 
. 

denke ich, diese Fäden feststecken, so dass ich auch einen anderen Thread-Dump (um zu sehen, was auf der nativen Methode geschieht):

00007faa1dabf6d5  __pthread_cond_wait + 0xc5 
0x00007faa1cb638ad  _ZN15JvmtiRawMonitor9raw_enterEP6Thread + 0x25d 
0x00007faa1cb3f63d  _ZN8JvmtiEnv15RawMonitorEnterEP15JvmtiRawMonitor + 0xad 
0x00007faa1b7089a8  debugMonitorEnter + 0x38 
0x00007faa1b6f5205  event_callback + 0xe5 
0x00007faa1b6f5e3e  cbClassPrepare + 0x8e 
0x00007faa1cb548c4  _ZN11JvmtiExport18post_class_prepareEP10JavaThreadP12klassOopDesc + 0x1b4 
0x00007faa1ca1de8e  _ZN13instanceKlass15link_class_implE19instanceKlassHandlebP6Thread + 0x45e 
0x00007faa1cae55c7  JVM_GetClassDeclaredConstructors + 0x1b7 
0x00007faa180cac39  * java.lang.Class.getDeclaredConstructors0(boolean) bci:0 (Interpreted frame) 

Kann mir jemand sagen, warum habe ich Streit hier?

Answer 1

Das Problem war, dass ich startete Tomcat im Debug-Modus (Jpda Start). Obwohl ich keinen Debugger angeschlossen habe, hat es Probleme verursacht. Als ich Tomcat ohne Debug gestartet habe, habe ich die festgefahrene Methode nicht bemerkt.

Answer 2

Nun, lassen Sie mich versuchen, Ihnen zu antworten. Ich gehe davon aus, dass die obersten Einträge die innersten Anrufe sind.

Es ist in reflektiert, eine Methode aufgerufen wird, ist es schwer, was zu sagen, aber , dass sie eine oder mehr Methoden und Laufen erfordert die Erstellung und , die eine neue Instanz von java.lang.Class erfordert es, und , die einen Konstruktor der Klasse erfordert immer, und , die in die JVM ist gut, die ein Ereignis trifft, die es in debugMonitor fällt, die in einem Thread warten ist, möglicherweise hängt für Benutzereingaben im Debugger .

Also vielleicht müssen Sie sich einen anderen Thread ansehen? Oder vielleicht ist dies die richtige, und Sie müssen nur die Ebenen nach dem Event Callback ignorieren. In jedem Fall würde ich betrachten reflektieren, um zu sehen, ob es sich auf Ihre-Code bezieht. Das müssen Sie finden. Es ist nicht gut, tief in den Systemcode zu gehen, von dem Sie annehmen, dass er OK funktioniert.