线程转储分析

左手的ㄟ右手 2022-06-08 08:40 163阅读 0赞

http://www.yangguo.info/2015/04/01/%E7%BA%BF%E7%A8%8B%E8%BD%AC%E5%82%A8/

### 线程状态 ###

在具体分析线程转储数据之前，我们首先要明确线程的状态。**java.lang.Thread.State**枚举类中定义了如下几种类型：

1.  **NEW**：线程创建尚未启动。
2.  **RUNNABLE**：包括操作系统线程状态中的Ready和Running，可能在等待时间片或者正在执行。
3.  **BLOCKED**：线程被阻塞。
4.  **WAITING**：不会分配CPU执行时间，直到别的线程显式的唤醒，否则无限期等待。LockSupport.park()，没有设置Timeout参数的Object.wait()和Thread.join()，会导致此现象。
5.  **TIMED\_WAITING**：不会分配CPU执行时间，直到系统自动唤醒，不需要别的线程显示唤醒。Thread.sleep()，LockSupport.parkNanos()，LockSupport.parkUntil()，设置了超时时间的Object.wait()和Thread.join()，会让线程进入有限期等待。
6.  **TERMINATED**：线程执行结束。

> 很多人分不清楚**阻塞**和**等待**的区别，导致在分析线程转储时出现偏差。阻塞状态与等待状态的区别是：阻塞状态的线程是在等待一个排它锁，直到别的线程释放该排它锁，该线程获取到该锁才能退出阻塞状态；而等待状态的线程则是等待一段时间，由系统唤醒或者别的线程唤醒，该线程便退出等待状态。

线程状态转化见下图：  
[![thread\_state][thread_state]][thread_state]

在任意一个时刻，线程只能处于其中的一种状态。

上面的状态颗粒度比较大，stackoverflow上有个哥们将状态定义为如下11种。在我们强制dump出来的转储中，更多的是表现为如下状态中的一种。至于这11种状态的是否权威，不敢妄下定论。原文[见此][Link 1]

1.  NEW: Just starting up, i.e., in process of being initialized.
2.  NEW\_TRANS: Corresponding transition state (not used, included for completness).
3.  IN\_NATIVE: Running in native code.
4.  IN\_NATIVE\_TRANS: Corresponding transition state.
5.  IN\_VM: Running in VM.
6.  IN\_VM\_TRANS: Corresponding transition state.
7.  IN\_JAVA: Running in Java or in stub code.
8.  IN\_JAVA\_TRANS: Corresponding transition state (not used, included for completness).
9.  BLOCKED: Blocked in vm.
10. BLOCKED\_TRANS: Corresponding transition state.
11. UNINITIALIZED

java的线程转储指的是JVM中在某一个给定的时刻运行的所有线程的快照。一个线程转储可能包含一个单独的线程或者多个线程。在多线程环境中，如Java EE应用服务器，将会有许多线程和线程组。转储中的每一个线程都有一自己独立的逻辑，这些逻辑信息将会在堆栈信息中体现。

线程转储可以通过如下的方式生成：

1.  Unix：kill -3 ，输出到了/proc//fd/1
2.  Windows：CTRL+BREAK
3.  jstack：jstack >> 输出文件

在Linux上，大家可能都碰见过这样的问题：

就是用jstack 是拿不到thread dump的，必须加**-F**来强制dump。上面的问题是其实很简单，就是pid路径问题导致的，Google一下就清楚了。我想说的是，加**-F** dump出来的内容是不能用[TDA][]分析的。如果不是真正的进程挂起，如果又想使用**TDA**进行分析的话，可以使用第一种方式进行dump。但有时候，的确必须要使用**-F**才能获得dump信息，比如程序挂起了。由于jstack -F/m就会使用到**SA**(The Serviceability Agent)，我们平常不加-F/-m的时候默认走的是**Instrumentation**的**attach**操作，知道这点非常重要。

### 转储说明 ###

线程转储生成好之后，我们便可以开始着手分析转储信息了，下面会给出几个例子逐一分析。

**例子1**

<table style="border-collapse:collapse; border-spacing:0px; margin:0px; width:auto; border:none; font-size:14px; table-layout:fixed"> 
 <tbody> 
 <tr style="background-color:rgb(249,249,249)"> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; font-family:&quot;PT Mono&quot;,consolas,Menlo,&quot;PingFang SC&quot;,&quot;Microsoft YaHei&quot;,monospace; font-size:13px; margin-top:0px; margin-bottom:0px; padding:10px; color:rgb(102,102,102); background:rgb(41,41,41); line-height:1.6; border:none; text-align:right">1
2
3
4
5
6
7
8
9
10
11
12
</pre> </td> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; font-family:&quot;PT Mono&quot;,consolas,Menlo,&quot;PingFang SC&quot;,&quot;Microsoft YaHei&quot;,monospace; font-size:13px; margin-top:0px; margin-bottom:0px; padding:10px; color:rgb(234,234,234); background:rgb(0,0,0); line-height:1.6; border:none">"http-bio-8080-exec-1-SendThread(192.168.161.36:2181)" daemon prio=10 tid=0x00007f797425b800 nid=0x3884 runnable [0x00007f79795ac000]
 java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:228)
	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
	- locked &lt;0x00000000f2bf18e0&gt; (a sun.nio.ch.Util$2)
	- locked &lt;0x00000000f2bf18f0&gt; (a java.util.Collections$UnmodifiableSet)
	- locked &lt;0x00000000f2bf1898&gt; (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
	at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:349)
	at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
</pre> </td> 
 </tr> 
 </tbody> 
</table>

*  http-bio-8080-exec-1-SendThread(192.168.161.36:2181)：线程的名字
 *  daemon：守护线程
 *  prio=10：线程的优先级（默认是5）
 *  tid：Java的线程Id（线程在当前虚拟机中的唯一标识）
 *  nid：线程本地标识
 *  runnable：线程的状态
 *  \[0x00007f79795ac000\]：当前运行的线程在堆中的地址范围

这个线程转储的剩余部分是调用堆栈，这个线程（http-bio-8080-exec-1-SendThread(192.168.161.36:2181)）是操作系统守护线程，当前正在执行一个本地方法epollWait。该native线程正处于RUNNABLE的状态，

**例子2**

<table style="border-collapse:collapse; border-spacing:0px; margin:0px; width:auto; border:none; font-size:14px; table-layout:fixed"> 
 <tbody> 
 <tr style="background-color:rgb(249,249,249)"> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; font-family:&quot;PT Mono&quot;,consolas,Menlo,&quot;PingFang SC&quot;,&quot;Microsoft YaHei&quot;,monospace; font-size:13px; margin-top:0px; margin-bottom:0px; padding:10px; color:rgb(102,102,102); background:rgb(41,41,41); line-height:1.6; border:none; text-align:right">1
2
3
4
5
6
7
8
9
10
11
12
13
</pre> </td> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; font-family:&quot;PT Mono&quot;,consolas,Menlo,&quot;PingFang SC&quot;,&quot;Microsoft YaHei&quot;,monospace; font-size:13px; margin-top:0px; margin-bottom:0px; padding:10px; color:rgb(234,234,234); background:rgb(0,0,0); line-height:1.6; border:none">"http-bio-8080-exec-1" daemon prio=10 tid=0x0000000002172800 nid=0x3882 waiting on condition [0x00007f798c292000]
 java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for &lt;0x00000000f2a44710&gt; (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.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
	at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
</pre> </td> 
 </tr> 
 </tbody> 
</table>

该转储表示守护线程**http-bio-8080-exec-1**会一直等待，直到ThreadPoolExecutor上有需要执行的任务分配给该线程执行(LockSupport.unpark)，它才能从LockSupport.park中解脱出来。

**例子3**

<table style="border-collapse:collapse; border-spacing:0px; margin:0px; width:auto; border:none; font-size:14px; table-layout:fixed"> 
 <tbody> 
 <tr style="background-color:rgb(249,249,249)"> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; font-family:&quot;PT Mono&quot;,consolas,Menlo,&quot;PingFang SC&quot;,&quot;Microsoft YaHei&quot;,monospace; font-size:13px; margin-top:0px; margin-bottom:0px; padding:10px; color:rgb(102,102,102); background:rgb(41,41,41); line-height:1.6; border:none; text-align:right">1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
</pre> </td> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; font-family:&quot;PT Mono&quot;,consolas,Menlo,&quot;PingFang SC&quot;,&quot;Microsoft YaHei&quot;,monospace; font-size:13px; margin-top:0px; margin-bottom:0px; padding:10px; color:rgb(234,234,234); background:rgb(0,0,0); line-height:1.6; border:none">"RMI Scheduler(0)" daemon prio=9 tid=7f94661c1800 nid=0x11b479000 waiting on condition [11b478000]
 java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for &lt;7f40deae0&gt; (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
	at java.util.concurrent.DelayQueue.take(DelayQueue.java:164)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:957)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:917)
	at java.lang.Thread.run(Thread.java:695)

 Locked ownable synchronizers:
	- None
</pre> </td> 
 </tr> 
 </tbody> 
</table>

线程**RMI Scheduler**不会分配CPU执行时间，直到系统自动唤醒，不需要别的线程显示唤醒。它由于调用了LockSupport.parkNanos()进入了有限期等待。

--------------------

### 案例分析 ###

#### CPU负载高 ####

Java进程CPU占用率居高不下，导致系统吞吐率下降，这种问题对很多初级码农来说简直就是梦魇。如果想快速的定位CPU高的原因，线程转储绝对是第一选择。CPU过高一般原因分为CPU密集型和死循环，这两种情况我们分开来分析。

死循环分析非常简单，步骤如下：

1.  在CPU占用率高的时候，通过**top -H**或者**ps H -eo user,pid,ppid,tid,time,%cpu,cmd –sort=%cpu**将CPU占用率高的线程的tid给找出来，并即时线程转储。
2.  将上面的找到的tid进行转化为16进制，然后在线程转储中查找对应的线程号，都会找到对应的nid标示。
3.  定位之后，通过转储中的精确的行号，可以定位到代码中相应的位置，便可以迅速确定原因。

死循环一般是逻辑错误导致的，我们在代码中应该慎用自旋。在一些带有状态机逻辑的代码中，加入次数限制，防止程序跑飞。

CPU密集型分析跟死循环不一样，因为你通过查看线程的CPU使用率，你会发现每个线程都不是很高，但是多个加起来之后就不容乐观。这类问题，步骤如下：

1.  在CPU占用率高的时候，通过**top -H**或者**ps H -eo user,pid,ppid,tid,time,%cpu,cmd –sort=%cpu**将CPU占用率高的前10个线程的tid给找出来，并即时线程转储。
2.  将上面的找到的tid进行转化为16进制，然后在线程转储中查找对应的线程号，将能够找到的部分标记出来。
3.  然后在标记出来的线程转储中寻找共性。如果通过所有的线程转储，发现线程正在执行同一个方法（同样的行号），几乎就可以确定这就是罪魁祸首了。那就可以查看代码，来做代码级别的分析了，问题便迎刃而解了。

CPU密集型，一般原因是算法效率低导致的。例如，正则表达式写的差，该用Map或者Set结构的却用了List来遍历。

线程占用CPU的类型可以分为如下两种：

us:用户空间占用CPU百分比

sy:内核空间占用CPU百分比

在linux下可以通过top命令查看详细，示例如下：

CPU us高的原因主要是执行线程不需要任何挂起动作，且一直执行，导致CPU没有机会去调度执行其他的线程，我们上面分析的都属于这类情况。

CPU sy高的原因主要是线程的运行状态要经常切换，对于这种情况，常见的一种优化方法是减少线程数。

--------------------

#### 响应慢(低负载) ####

相应时间长，一般出现在高负载的机器上。如果在CPU的占用率很低，只有几个线程在消耗CPU的时间片，然而应用的响应时间却很长，我们首先要想到的是IO操作出现问题，至于到底是网络IO还是本地IO，我们就可以通过线程转储来定位。定位到位置之后，可以使用缓存或者减少IO操作来提升系统响应速度。

--------------------

#### 应用/服务宕机 ####

当一个应用活着却不能完成任何响应的时候，表明该服务已经宕机。

此时分析线程转储，会发现大量的线程在同一个操作中罢工了，没有任何一个线程能够完成自己的操作，从而导致该JVM再没有可用的线程。很多时候都是由于死锁导致的，当一个线程持有一个对象锁而不释放，而别的线程都在等待该锁的时候便会发生死锁现象。幸运的是JVM通常会检测死锁，通过工具分析转储能够更快的定位到原因。如果想避免复杂的死锁，我们需要尽可能减小同步块的大小，并且在进行资源的访问时设置合理的超时时间，避免死等现象。

综上所述，如果能够熟练分析线程转储，就可以在较短时间内识别，诊断，检测和解决生产环境的问题，这对于需要7\*24服务的应用来说必备的技能之一。

[thread_state]: http://www.yangguo.info/images/thread_state.png
[Link 1]: http://stackoverflow.com/questions/1827543/java-threads-interpreting-thread-states-of-a-running-jvm
[TDA]: https://java.net/projects/tda