Анализ зацикленных потоков по собственному методу

Question

Я использую tomcat и java 1.7.0_80. Продукт является двигателем правил с использованием слюни. У меня наблюдается спад после загрузки системы. Я взял нить дамп и увидеть много потоков, которые выглядят как:

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

Я думаю, что эти потоки застряли, так что я другой поток дамп (чтобы увидеть, что происходит на родной метод):

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) 

Может кто-нибудь сказать мне, почему у меня есть соперничество здесь?

Answer 1

Проблема в том, что я начал tomcat в режиме отладки (запуск jpda). Несмотря на то, что я не подключил отладчик, это вызвало проблемы. Когда я запустил tomcat без отладки, я не заметил застрявшего метода.

Answer 2

Хорошо, позвольте мне попытаться ответить вам. Я собираюсь сделать предположение, что самые верхние записи являются самыми внутренними вызовами.

Это в отражают, ссылаясь на какой-то метод, это трудно сказать, что, но , что требует создания одного или нескольких методов и запуская их, и , что требует внесения в новый экземпляр java.lang.Class, и , что требует при получении конструктор класса, и что окунается в JVM, которая попадает событие, которое падает его в debugMonitor, который находится в нити ожидания, вполне возможно, висит на входе пользователя в отладчике ,

Возможно, вам нужно посмотреть на другой поток? Или, может быть, это правильный вариант, и вам просто нужно игнорировать уровни, прошедшие после обратного вызова. В любом случае, я бы посмотрел на то, что отражает, чтобы узнать, относится ли это к ваш код. Вот что вам нужно найти. Нехорошо вникать в системный код, который, по вашему мнению, работает нормально.