Le vidage de thread Java où le thread principal n'a pas de pile d'appel? (jsvc)

Question

Nous avons un processus Java exécuté en tant que démon (sous jsvc). Tous les jours, il arrête de faire n'importe quel travail; la sortie vers le fichier journal s'arrête (elle est plutôt bavarde, à intervalles de 5 minutes) et ne consomme pas d'unité centrale ou d'E/S.

Aucune exception n'est consignée dans le fichier journal ni dans syserr ou sysout. La dernière instruction log est juste avant la validation db, mais il n'y a pas de connexion ouverte sur le serveur db (MySQL) et en passant en revue le code, il devrait toujours y avoir une sortie de journal supplémentaire, même si elle a rencontré une exception allait faire des bulles.

La chose la plus curieuse, je trouve que dans la décharge de fil (inclus ci-dessous), il n'y a pas de fil dans notre code du tout, et le thread principal semble avoir aucun contexte que ce soit:

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

Comme indiqué plus tôt, il s'agit d'un démon en cours d'exécution utilisant jsvc, mais je ne sais pas si cela a quelque chose à voir avec ça (je peux restructurer le code pour permettre aussi de l'exécuter directement, pour tester).

Des suggestions sur ce qui pourrait se passer ici?

Merci ... DWH

vidage filet plein:

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

Tous les Throwables sont des exceptions. Est-ce que votre code de journalisation des erreurs rencontre des erreurs (OutOfMemoryError, StackOverflowError, etc)?

Answer 2

Un autre couple de possibilités:

• L'exception pourrait être jeté sur un être thread de travail qui ne se connecte pas des exceptions. Vous pouvez résoudre ce problème en utilisant Thread.setDefaultUncaughtExceptionHandler (...). L'exception qui est levée peut remplacer la méthode Throwable.fillInStackTrace(). (Ceci est une vue longue ... mais apparemment certaines personnes font ceci dans une tentative malencontreuse d'empêcher l'ingénierie inverse.)