程序完成后，Java會掛起一分鍾

Question

我們在大型應用程序的構建過程中使用了Java命令行實用程序。 從最近（顯然是在將Java升級到OpenJDK運行時環境（版本1.8.0_212-b04）之后 - 經常沒有使用該程序，所以我沒有注意到這是什么時候開始發生）它在main()之后掛了大約一分鍾main()已經完成了。 即它掛在Java內部的某個地方， 而不是在我們的代碼中 ，盡管我們的代碼可能以某種方式間接導致這種情況。

該程序使用Javassist（3.25）來檢測以前使用javac編譯的一些Java類。 不幸的是，我不能發布程序本身，因為它非常龐大，復雜且專有。

掛起程序大約一分鍾后正常退出 - 進程返回代碼為零，沒有任何內容打印到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

Answer 1

好的，結果證明它不是bug，與Java升級無關。 這是因為Executors.newCachedThreadPool()使用非守護程序線程，這導致應用程序在最后一個任務完成后一分鍾保持活動狀態。 （池一直在那里，但最近我們的應用程序中的一個更改向它提交了一個任務，所以它變得非空。）

所以我需要在它上面調用shutdown()或者使用這個問題的答案來創建一個守護程序線程池。