Дамп потока Java, где основной поток не имеет стека вызовов? (jsvc)

Question

У нас есть java-процесс, выполняющийся как демон (под jsvc). Каждые несколько дней он просто прекращает делать какую-либо работу; вывод в лог-файл останавливается (он довольно многословный, с 5-минутными интервалами), и он не потребляет CPU или IO.

В журнале нет исключений, кроме syserr или sysout. Последний оператор журнала находится непосредственно перед выполнением db-commit, но нет открытого соединения на сервере db (MySQL) и просмотра кода, после этого всегда должен быть дополнительный выход журнала, даже если он столкнулся с исключением, которое собирался взорваться.

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

"main" prio=10 tid=0x0000000000614000 nid=0x445d runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

Как отмечалось Раньше это демон-процесс, выполняющийся с помощью jsvc, но я не знаю, имеет ли это какое-либо отношение к нему (я могу реструктурировать код, чтобы он также мог запускать его напрямую, чтобы проверить).

Любые предложения о том, что может происходить здесь?

Спасибо ... DWH

Полный поток свалка:

Full thread dump Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode): 

"MySQL Statement Cancellation Timer" daemon prio=10 tid=0x00002aaaf81b8800 nid=0x447b in Object.wait() [0x00002aaaf6a22000] 
    java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
- waiting on <0x00002aaab5556d50> (a java.util.TaskQueue) 
at java.lang.Object.wait(Object.java:485) 
at java.util.TimerThread.mainLoop(Timer.java:483) 
- locked <0x00002aaab5556d50> (a java.util.TaskQueue) 
at java.util.TimerThread.run(Timer.java:462) 

"Low Memory Detector" daemon prio=10 tid=0x00000000006a4000 nid=0x4479 runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"CompilerThread1" daemon prio=10 tid=0x00000000006a1000 nid=0x4477 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"CompilerThread0" daemon prio=10 tid=0x000000000069d000 nid=0x4476 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Signal Dispatcher" daemon prio=10 tid=0x000000000069b000 nid=0x4465 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Finalizer" daemon prio=10 tid=0x0000000000678800 nid=0x4464 in Object.wait() [0x00002aaaf61d6000] 
    java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
- waiting on <0x00002aaab54a1cb8> (a java.lang.ref.ReferenceQueue$Lock) 
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) 
- locked <0x00002aaab54a1cb8> (a java.lang.ref.ReferenceQueue$Lock) 
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) 
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) 

"Reference Handler" daemon prio=10 tid=0x0000000000676800 nid=0x4463 in Object.wait() [0x00002aaaf60d5000] 
    java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
- waiting on <0x00002aaab54a1cf0> (a java.lang.ref.Reference$Lock) 
at java.lang.Object.wait(Object.java:485) 
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) 
- locked <0x00002aaab54a1cf0> (a java.lang.ref.Reference$Lock) 

"main" prio=10 tid=0x0000000000614000 nid=0x445d runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"VM Thread" prio=10 tid=0x0000000000670000 nid=0x4462 runnable 

"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000000061e000 nid=0x445e runnable 

"GC task thread#1 (ParallelGC)" prio=10 tid=0x0000000000620000 nid=0x445f runnable 

"GC task thread#2 (ParallelGC)" prio=10 tid=0x0000000000622000 nid=0x4460 runnable 

"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000000623800 nid=0x4461 runnable 

"VM Periodic Task Thread" prio=10 tid=0x00000000006a6800 nid=0x447a waiting on condition 

JNI global references: 797 

Heap 
PSYoungGen  total 162944K, used 48388K [0x00002aaadff40000, 0x00002aaaf2ab0000, 0x00002aaaf5490000) 
    eden space 102784K, 47% used [0x00002aaadff40000,0x00002aaae2e81170,0x00002aaae63a0000) 
    from space 60160K, 0% used [0x00002aaaeb850000,0x00002aaaeb850000,0x00002aaaef310000) 
    to space 86720K, 0% used [0x00002aaae63a0000,0x00002aaae63a0000,0x00002aaaeb850000) 
PSOldGen  total 699072K, used 699072K [0x00002aaab5490000, 0x00002aaadff40000, 0x00002aaadff40000) 
    object space 699072K, 100% used [0x00002aaab5490000,0x00002aaadff40000,0x00002aaadff40000) 
PSPermGen  total 21248K, used 9252K [0x00002aaab0090000, 0x00002aaab1550000, 0x00002aaab5490000) 
    object space 21248K, 43% used [0x00002aaab0090000,0x00002aaab09993e8,0x00002aaab1550000) 

Answer 1

Не все Throwables исключения. Копирует ли ваш код регистрации ошибок ошибки (OutOfMemoryError, StackOverflowError и т. Д.)?

Answer 2

Еще несколько возможностей:

• Исключение может быть выброшен на рабочий поток, который не регистрирует исключения. Вы можете решить эту проблему, используя Thread.setDefaultUncaughtExceptionHandler (...).

• Исключенное исключение может переопределить метод Throwable.fillInStackTrace(). (Это длинный выстрел ... но, по-видимому, некоторые люди делают это в ошибочной попытке предотвратить обратную инженерию.)