我的一个应用程序在负载下运行一段时间后挂起,有谁知道什么可能导致 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。
有趣的是,这只发生在其中一个应用程序实例上。另外两个运行良好。在这种情况下,我还能调查什么以获得更多细节?
我发现这篇文章 https://stackoverflow.com/questions/23992787/parking-to-wait-for-0xd8cf0070-a-java-util-concurrent-locks-abstractqueueds 但它对我来说不是很有用。
原文由 Konrad Pawlus 发布,翻译遵循 CC BY-SA 4.0 许可协议
unsafe.park 与 thread.wait 几乎相同,只是它使用特定于体系结构的代码(因此是“不安全”的原因)。 unsafe 未公开提供,但在 java 内部库中使用,其中特定于体系结构的代码将提供显着的优化优势。它被大量用于线程池。
所以,为了回答你的问题,线程所做的只是等待某事,它并没有真正使用任何 CPU。考虑到您的原始堆栈跟踪显示您正在使用锁,我认为您的情况正在发生死锁。
是的,我知道你现在几乎肯定已经解决了这个问题。但是,如果有人用 google 搜索 sun.misc.unsafe.park,您就是最佳结果之一。我想回答这个问题可能会帮助其他人试图理解这种似乎正在使用他们所有 CPU 的方法是什么。