Thread.State: WAITING (parking) vs BLOCKED at sun.misc.Unsafe.park() 有什么区别答案

【问题标题】：What is the difference between Thread.State: WAITING (parking) vs BLOCKED at sun.misc.Unsafe.park()Thread.State: WAITING (parking) vs BLOCKED at sun.misc.Unsafe.park() 有什么区别
【发布时间】：2020-09-29 06:03:42
【问题描述】：

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

在生产服务器上，线程被阻塞（500 个中有 337 个）。在开发环境中，没有线程被阻塞（50% 为 runnable 和 50% 为 waiting 在 60 个线程中）。

那些阻塞线程是否在等待某些线程无限期持有的同步块？ 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)

【问题讨论】：

标签： java multithreading performance threadpool hazelcast

【解决方案1】：

这些线程转储无法合理比较，因为它们是通过不同的方式获得的。第一个是使用 Serviceability Agent 以“强制”模式 (-F) 进行的。第二个是通过 Attach API 进行的“正常”转储。区别解释here。

输出的含义也不同。 “正常”转储显示java.lang.Thread 对象的状态，而“强制”转储显示相应VM 线程的状态。从 JVM 的角度来看，线程可以处于IN_NATIVE、IN_VM、IN_JAVA 状态之一，处于转换状态或BLOCKED 状态。 BLOCKED 基本上是指任何不可运行的状态，包括线程处于休眠、等待或停放的状态。

在您的第一次转储中，BLOCKED 线程在 Unsafe.park 方法中 - 似乎它们只是空闲并且不太可能导致问题。

WAITING 或 TIMED_WAITING 是 Java 级别 Thread.State 的值。您只能在“正常”转储中看到它们，即没有-F 选项。

当您无法进行“正常”转储时，这通常意味着目标 JVM 正忙于长时间运行的安全点操作（例如，Full GC），或者进程没有收到 CPU 时间（例如，它耗尽内存并开始交换）。在这种情况下，像perf 这样的操作系统级别分析器可能很有用。

【讨论】：

【解决方案2】：

Thread states - 这里是线程状态的一点解释。

新功能 该线程尚未开始。

可运行 线程正在JVM中执行。

已屏蔽 线程被阻塞等待监视器锁。

等待中 线程无限期地等待另一个线程执行特定操作。

TIMED_WAITING 该线程正在等待另一个线程执行操作，最长等待时间达到指定的等待时间。

终止线程已退出。

BLOCKED 状态是否会在同一线程中长时间存在，这应该是令人担忧的。这当然取决于您的情况 - 您如何处理数据、如何创建线程（和线程池）、您的关键部分是什么以及所有这些部分如何相互交互。

生产的单个线程转储是不够的 - 您应该进行多个转储和 - 比较发生的事情和 - 线程运行/等待多长时间 - 这是在高负载时发生还是在高负载后发生 - 你的线程数是否会随着时间的推移而增加，等等。

因此，无法判断在这个特定时间点有 500 个阻塞线程是好是坏，但可以肯定的是，这是令人担忧的。一个线程大约需要 2MB 来初始化和分配，所以它是 1GB 的内存。

很可能有一些关键部分被某些线程占用，从而导致您的问题和应用程序无响应。您可能会使用阻塞方法等从队列中读取一些非常复杂的情况。

可能的行动方案：

进行多个转储并进行比较 - 发生了什么变化？哪些线程仍然被阻塞？
检查您是否可以在转储的堆栈跟踪中查明阻塞线程中的调用（仅是您的包前缀或 java 的/hazelcast 的包）。
使用跟踪工具（flight-recorder / jvisualvm）检查线程的增长情况以及线程（被阻塞的）创建时间 - 应用此时正在做什么？
根据阻塞调用和同步方法/使用的潜在误用分析您的代码库。
在达到限制时检查线程池的最大大小和工作队列的实现和策略（例如，了解RejectedExecutionHandler 的实现）

【讨论】：