У нас есть служебная программа командной строки Java, используемая в процессе сборки большого приложения. С недавнего времени (видимо после обновления Java до OpenJDK Runtime Environment (сборка 1.8.0_212-b04) — программа используется не так часто, поэтому я не заметил, когда именно это начало происходить) зависает примерно на минуту после того, как main()
законченный. т.е. он зависает где-то внутри Java, не в нашем коде, хотя наш код может как-то косвенно вызывать это.
Программа использует Javassist (3.25) для обработки некоторых классов Java, которые ранее были скомпилированы с помощью javac
. К сожалению, саму программу выложить не могу, так как она достаточно большая и сложная, к тому же проприетарная.
Примерно через минуту зависания программа завершается нормально — код возврата процесса равен нулю, ни в stderr, ни в stdout ничего не выводится. Полученные результаты также соответствуют ожиданиям.
Ниже приведен дамп стека потоков, извлеченный утилитой jstack
из таким образом «зависшего» процесса. Как видите, больше нет потоков, выполняющих что-либо из нашей программы, все потоки на данный момент находятся внутри Java.
Кто-нибудь сталкивался с чем-то подобным или есть идеи, что происходит?
2019-05-22 12:51:34
Full thread dump OpenJDK 64-Bit Server VM (25.212-b04 mixed mode):
"Attach Listener" #12 daemon prio=9 os_prio=0 tid=0x00007f196c001000 nid=0x3c3a waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"DestroyJavaVM" #11 prio=5 os_prio=0 tid=0x00007f19c0059800 nid=0x3b6c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"pool-1-thread-1" #10 prio=5 os_prio=0 tid=0x00007f19c0d1b800 nid=0x3b8e waiting on condition [0x00007f1985f21000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000776280730> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007f19c0145800 nid=0x3b87 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f19c013a000 nid=0x3b86 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f19c0138000 nid=0x3b85 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f19c0136000 nid=0x3b84 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f19c0133000 nid=0x3b83 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f19c0126800 nid=0x3b82 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f19c00fa800 nid=0x3b81 in Object.wait() [0x00007f198727c000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000776289088> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- locked <0x0000000776289088> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f19c00f5800 nid=0x3b80 in Object.wait() [0x00007f198737d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000776280990> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x0000000776280990> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"VM Thread" os_prio=0 tid=0x00007f19c00ec000 nid=0x3b7f runnable
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f19c006c000 nid=0x3b6d runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f19c006e000 nid=0x3b76 runnable
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f19c0070000 nid=0x3b77 runnable
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f19c0071800 nid=0x3b78 runnable
"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00007f19c0073800 nid=0x3b79 runnable
"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00007f19c0075800 nid=0x3b7a runnable
"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00007f19c0077000 nid=0x3b7d runnable
"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00007f19c0079000 nid=0x3b7e runnable
"VM Periodic Task Thread" os_prio=0 tid=0x00007f19c0148000 nid=0x3b88 waiting on condition
JNI global references: 313
Хорошо, оказалось, что это не ошибка и не имеет ничего общего с обновлением Java. Это связано с тем, что Executors.newCachedThreadPool()
использует потоки, не являющиеся демонами, из-за чего приложение остается в живых через минуту после завершения последней задачи. (Пул всегда был там, но недавнее изменение в нашем приложении отправило в него задачу, поэтому он стал непустым.)
Поэтому мне нужно либо вызвать shutdown()
, либо использовать ответы на этот вопрос для создания пула потоков демона.
Подсказка в дампе потока — это поток "pool-1-thread-1"
, в котором отсутствует флаг daemon
, и поэтому он поддерживает работу программы.
Хорошее место, согласно документам «Потоки, которые не использовались в течение шестидесяти секунд, завершаются и удаляются из кеша».
Можно ли запустить его в отладчике и "ломать" при зависании. Основываясь на трассировке стека, что-то все еще работает и отказывается выходить. У вас есть какой-нибудь поток, который просыпается каждую минуту или около того? Если нет, проверьте потоки с помощью отладчика и посмотрите, чего он ожидает (конкретно изучите потоки Object.wait(), и tryHandlePending может означать, что это часть блока попытки, пытающегося очиститься).