城的灯

线程转储分析

发表于 | 分类于

最近好几个同事都向我问起过java线程转储方面的知识，都是些常见的问题，如：系统负载过高，系统吞吐率降低，系统挂起等等。这些问题的定位和解决都离不开线程转储，因为这些问题在测试环境复现的难度较大，只有在生产环境进行ThreadDump，才能快速定位问题。

线程状态

在具体分析线程转储数据之前，我们首先要明确线程的状态。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

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

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

  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上，大家可能都碰见过这样的问题：

1
2
Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

就是用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

1
2
3
4
5
6
7
8
9
10
11
12
"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 <0x00000000f2bf18e0> (a sun.nio.ch.Util$2)
	- locked <0x00000000f2bf18f0> (a java.util.Collections$UnmodifiableSet)
	- locked <0x00000000f2bf1898> (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)
  • 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

1
2
3
4
5
6
7
8
9
10
11
12
13
"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  <0x00000000f2a44710> (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)

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

例子3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
"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  <7f40deae0> (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

线程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命令查看详细，示例如下：

1
Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 99.3%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st

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

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

响应慢(低负载)

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

应用/服务宕机

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

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

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