Thread.State：在sun.misc.Unsafe.park（）上等待（停车）与BLOCKED有什么区别？>

Question

我有一个连接到Hazelcast的应用程序。最近，我发现对hazelcast的请求最终开始变得没有响应，因此，我进行了Hazelcast进程的线程转储。在分析来自开发和生产环境的线程转储时，我发现在池中等待任务的线程在不同环境中处于不同状态。

虽然在生产服务器上，但是这些线程被阻止

（500个中的337个）。在开发环境中，不会阻塞任何线程（60个线程中有50％作为runnable和50％作为waiting）。

那些阻塞线程是否正在等待某些线程无限期持有的同步块？ 500个线程是否太多（某些分析器发出警告）？这是否导致我的应用程序无响应？

此状态可能是什么原因，以及如何解决此问题？

线程转储（生产）：

Thread 120713: (state = BLOCKED)
     - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
     - java.util.concurrent.ForkJoinPool.awaitWork(java.util.concurrent.ForkJoinPool$WorkQueue, int) @bci=350, line=1824 (Compiled frame)
     - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=44, line=1693 (Interpreted frame)
     - java.util.concurrent.ForkJoinWorkerThread.run() @bci=24, line=157 (Interpreted frame)

Thread 120743: (state = BLOCKED)
    - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
    - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Compiled frame)
    - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() @bci=42, line=2039 (Compiled frame)
    - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled frame)
    - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1074 (Compiled frame)

Thread 120743: (state = BLOCKED)
    - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
    - java.util.concurrent.locks.LockSupport.park() @bci=5, line=304 (Compiled frame)
    - com.hazelcast.internal.util.concurrent.MPSCQueue.takeAll() @bci=83, line=231 (Compiled frame)
    - com.hazelcast.internal.util.concurrent.MPSCQueue.take() @bci=12, line=153 (Compiled frame)
    - com.hazelcast.client.spi.impl.ClientResponseHandlerSupplier$ResponseThread.doRun() @bci=17, line=164 (Compiled

Thread 128753: (state = BLOCKED)
    - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
    - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) @bci=20, line=215 (Compiled frame)
    - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long) @bci=78, line=2078 (Compiled frame)
    - java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take() @bci=124, line=1093 (Compiled frame)
    - java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take() @bci=1, line=809 (Compiled frame)
来自开发环境的线程转储：

java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006c1a1bc38> (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)
    

我有一个连接到Hazelcast的应用程序。最近，我发现对hazelcast的请求最终开始变得没有响应，因此，我进行了Hazelcast进程的线程转储。而...

Answer 1

Answer 2