在sun.misc.Unsafe.park等待(原生方法)

Question

我的一个应用程序在负载运行的一段时间内挂起,是否有人知道在jstack中可能导致此类输出的原因:

"scheduler-5" prio=10 tid=0x00007f49481d0000 nid=0x2061 waiting on condition [0x00007f494e8d0000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006ee117310> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1085)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)

当它挂起时,我在jstack输出中看到了很多.

我大量使用Spring @Async和地图,同步地图和ehcache.

有趣的是,这只发生在一个app实例上.另外两个人跑得很好.还有什么我可以调查以获得更多细节？

我发现这篇文章/sf/ask/1679495121/,但在我的情况下它并不是很有用.

Answer 1

unsafe.park与thread.wait几乎相同,只是它使用特定于体系结构的代码(因此它是"不安全"的原因).unsafe不公开,但在java内部库中使用,其中体系结构特定代码将提供显着的优化优势.它用于线程池.

所以,为了回答你的问题,所有线程正在做的是等待什么,它并没有真正使用任何CPU.考虑到您的原始堆栈跟踪显示您正在使用锁定,我认为在您的情况下会发生死锁.

是的我知道你现在几乎肯定已经解决了这个问题.但是,如果有人使用Google搜索sun.misc.unsafe.park,那么你就是最好的结果之一.我想回答这个问题可能会帮助其他人试图理解这种方法似乎正在使用他们所有的CPU.

Answer 2

从堆栈跟踪中可以清楚地看到,ThreadPoolExecutor> Worker线程已启动,并且它正在等待BlockingQueue(DelayedWorkQueue)上的任务可用于选择任务并执行.因此,只要获得一个该线程,该线程将处于WAIT状态.来自发布商线程的SIGNAL.