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

时间:2014-06-16 10:14:19

标签: java multithreading concurrency java.util.concurrent

我的一个应用程序在负载运行的某段时间内挂起,是否有人知道在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&amp;地图,同步地图和ehcache的。

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

我发现这篇文章https://stackoverflow.com/questions/23992787/parking-to-wait-for-0xd8cf0070-a-java-util-concurrent-locks-abstractqueueds,但在我的案例中它并不是很有用。

3 个答案:

答案 0 :(得分:145)

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

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

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

答案 1 :(得分:6)

从堆栈跟踪中可以清楚地看到,ThreadPoolExecutor&gt;工作线程启动,它正在等待BlockingQueue(DelayedWorkQueue)上的任务可用于选择任务并执行。所以只要从发布者线程获得SIGNAL,该线程将处于WAIT状态。

答案 2 :(得分:1)

我有一个类似的问题,并按照以前的答案(谢谢!),我能够搜索并找到如何正确处理ThreadPoolExecutor终端。

在我的情况下,这只是修复了类似阻塞线程的逐步增加:

  • 我在finally子句中使用了ExecutorService::awaitTermination(x, TimeUnit)ExecutorService::shutdownNow()(如有必要)。
  • 有关信息,我使用以下命令来检测线程数&amp;列出锁定的线程:

    ps -u javaAppuser -L | wc -l <​​/ p>

    jcmd`ps -C java -o pid =`Thread.print&gt;&gt; threadPrintDayA.log

    jcmd`ps -C java -o pid =`Thread.print&gt;&gt; threadPrintDayAPlusOne.log

    cat threadPrint * .log | grep“pool-”| wc -l <​​/ p>