WAITING at sun.misc.Unsafe.park（本地方法） [英] WAITING at sun.misc.Unsafe.park(Native Method)

问题描述

我的一个应用程序在一段时间的负载下挂起，有人知道什么可能导致jstack中的输出：

 scheduler-5prio = 10 tid = 0x00007f49481d0000 nid = 0x2061等待条件[0x00007f494e8d0000] 
 java.lang.Thread.State：WAITING（parking）
 at sun.misc.Unsafe.park本地方法）
  - 停止等待< 0x00000006ee117310> （java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject）
在java.util.concurrent.locks.LockSupport.park（LockSupport.java:186）
在java.util.concurrent.locks。 AbstractQueuedSynchronizer $ ConditionObject.await（AbstractQueuedSynchronizer.java:2043）
在java.util.concurrent.ScheduledThreadPoolExecutor $ DelayedWorkQueue.take（ScheduledThreadPoolExecutor.java:1085）
在java.util.concurrent.ScheduledThreadPoolExecutor $ DelayedWorkQueue。 （ThreadPoolExecutor.java:1043）
在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1103）
在java.util.concurrent.ThreadPoolExecutor.getTask（ThreadPoolExecutor.java:1043） 
 at java.util.concurrent.ThreadPoolExecutor $ Worker.run（ThreadPoolExecutor.java:603）
 at java.lang.Thread.run（Thread.java:722）
  
 
 
 
当我挂起时，我在jstack输出中看到很多。
 
 
 
大量使用Spring @Async&地图，同步地图& ehcache。
 
 
 
有趣的是，这只会发生在一个应用程序实例上。另外两个运行完美。 
在这种情况下，我还能进行哪些调查以获取更多详细信息？
 
 
 
我发现这个帖子  - 停止等待< 0xd8cf0070> （a java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject），但它在我的情况下不是非常有用。
解决方案
 unsafe.park与thread.wait几乎相同，除了它使用架构特定的代码（因此它是'不安全'的原因）。 unsafe不是公开提供的，而是在java内部库中使用，其中体系结构特定的代码将提供显着的优化优势。它用于线程池。
 
 
 
所以，为了回答你的问题，所有的线程正在等待的东西，它不是真的使用任何CPU。考虑到你原来的堆栈跟踪显示你正在使用一个锁，我认为你的情况下会发生死锁。
 
 
 
是的，我知道你几乎肯定已经解决了这个问题到现在。但是，如果有人搜索sun.misc.unsafe.park，您就是其中一个顶级结果。我回答的问题可能有助于其他人试图理解这种方法似乎是使用所有的CPU是。
 
One of my applications hangs under some period of running under load, does anyone know what could cause such output in 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)
I am seeing this a lot in jstack output when it hangs.

I heavily using Spring @Async & maps, synchronized maps & ehcache.

What is interesting this only happens on one of app instances. Two others are running perfectly fine.
What else I could investigate to get more details in such case?

I found this post - parking to wait for <0xd8cf0070> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) but it is not very useful in my case.
解决方案
unsafe.park is pretty much the same as thread.wait, except that it's using architecture specific code (thus the reason it's 'unsafe'). unsafe is not made available publicly, but is used within java internal libraries where architecture specific code would offer significant optimization benefits. It's used a lot for thread pooling.

So, to answer your question, all the thread is doing is waiting for something, it's not really using any CPU. Considering that your original stack trace shows that you're using a lock I would assume a deadlock is going on in your case.

Yes I know you have almost certainly already solved this issue by now. However, you're one of the top results if someone googles sun.misc.unsafe.park. I figure answering the question may help others trying to understand what this method that seems to be using all their CPU is.

                        
这篇关于WAITING at sun.misc.Unsafe.park（本地方法）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！