主線程沒有調用堆棧的Java線程轉儲？ （jsvc）

Question

我們有一個作爲守護進程運行的java進程（在jsvc下）。每隔幾天它就停止做任何工作;輸出到日誌文件停止（這是相當詳細的，每隔5分鐘），它不消耗CPU或IO。

在日誌文件中以及syserr或sysout中都沒有記錄異常。最後的日誌語句就在數據庫提交完成之前，但數據庫服務器（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

並非所有將Throwable例外。您的錯誤日誌記錄代碼是否捕獲錯誤（OutOfMemoryError，StackOverflowError等）？

Answer 2

另一對夫婦的可能性：

• 唯一的例外可能被拋出的一個工作線程，不記錄異常。你可以通過使用Thread.setDefaultUncaughtExceptionHandler（...）來解決這個問題。

• 正在引發的異常可能會覆蓋Throwable.fillInStackTrace（）方法。 （這是一個遠投......但顯然有人這樣做是爲了防止逆向工程的錯誤嘗試。）