Java线程dump分析

Java线程dump分析金蝶中间件有限公司2013年3月14日版本历史 (2)目录 (3)第1章JAVA线程DUMP (4)1.1什么是J AVA线程D UMP (4)1.2如何生成 (4)第2章线程DUMP分析 (5)2.1JVM线程 (5)2.2线程状态分析 (5)2.2.1Runnable (5)2.2.2Waiting on condition (5)2.2.3Waiting for monitor entry 和in Object.wait() (6)2.3JDK5.0的LOCK (8)第3章案例分析 (9)3.1死锁 (9)3.2热锁 (9)1.1 什么是Java线程Dump线程Dump是非常有用的诊断Java应用问题的工具，每一个Java虚拟机都有及时生成显示所有线程在某一点状态的线程Dump的能力。

虽然各个Java虚拟机线程dump打印输出格式上略微有一些不同，但是线程dump出来的信息包含线程基本信息；线程的运行状态、标识和调用的堆栈；调用的堆栈包含完整的类名，所执行的方法，如果可能的话还有源代码的行数。

JVM（java虚拟机）中的许多问题都可以使用线程Dump文件来进行诊断，其中比较典型的包括线程阻塞，CPU 使用率过高，JVM Crash，堆内存不足，和类装载等问题。

1.2 如何生成在不同的操作系统下，产生线程DUMP的方式是不同的：1)在windows环境中在启动程序的控制台里敲：Ctrl - Break，线程的dump会产生在标准输出中（缺省标准输出就是控制台，如果对输出进行了重定向，则要查看输出文件）。

2)在unix，linux和MacOS 环境中在控制台中敲：Ctrl-\，或者，用“kill -3 <pid>”，或者“kill –QUIT <pid>”。

Pid是用所关注的JA V A进程号，您可以用“ps -ef | grep java”找到，或者使用JDK 5.0中的“jps -v”命令获得。

3)在各个操作系统平台，都可以用JDK 5.0工具包中的jstack <pid>这里要注意的是：1.不同的JAVA虚机的线程DUMP的创建方法和文件格式是不一样的，不同的JVM版本，dump信息也有差别。

本文中，只以SUN的hotspot JVM 5.0_06 为例。

在实际运行中，往往一次dump的信息，还不足以确认问题。

建议产生三次dump信息，如果每次dump都指向同一个问题，我们才确定问题的典型性。

2.1 JVM线程在线程中，有一些JVM内部的后台线程，来执行譬如垃圾回收，或者低内存的检测等任务，这些线程往往在JVM初始化的时候就存在，如下所示："Low Memory Detector" daemon prio=10 tid=0x081465f8 nid=0x7 runnable [0x00000000..0x00000000]如有红色标注的daemon字样，表明是后台线程。

实际分析中观察的更多的是用户线程，如下所示：其中包括：1.线程的一些基本信息：名称、优先级及id2.线程状态：waiting on condition3.线程的调用栈4.线程锁住的资源：locked <0x3f63d600>2.2 线程状态分析正如我们刚看到的那样，线程的状态是一个重要的指标，它会显示在线程Stacktrace的头一行结尾的地方。

2.2.1 R unnable该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。

2.2.2 W aiting on condition该状态出现在线程等待某个条件的发生。

具体是什么原因，可以结合stacktrace来分析。

最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。

在Java引入NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。

在NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。

如果发现有大量的线程都在处在Wait on condition，从线程stack看，正等待网络读写，这可能是一个网络瓶颈的征兆。

因为网络阻塞导致线程无法执行。

一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。

所以要结合系统的一些性能观察工具来综合分析，比如netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制; 观察cpu的利用率，如果系统态的CPU时间，相对于用户态的CPU时间比例较高，这些都指向由于网络带宽所限导致的网络瓶颈。

另外一种出现Wait on condition的常见情况是该线程在sleep，等待sleep的时间到了时候，将被唤醒。

2.2.3 W aiting for monitor entry 和in Object.wait()在多线程的JA V A程序中，实现线程之间的同步，就要说说Monitor。

Monitor是Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者Class的锁。

每一个对象都有，也仅有一个monitor。

下面这个图，描述了线程和Monitor之间关系，以及线程的状态转换图：从图中可以看出，每个Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“Waiting Thread”，分别在两个队列“Entry Set”和“Wait Set”里面等候。

在“Entry Set”中等待的线程状态是“Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是“in Object.wait()”。

先看“Entry Set”里面的线程。

我们称被synchronized保护起来的代码段为临界区。

当一个线程申请进入临界区时，它就进入了“Entry Set”队列。

对应的代码就像：这时有两种可能性：●该monitor不被其它线程拥有，Entry Set里面也没有其它等待线程。

本线程即成为相应类或者对象的Monitor的Owner，执行临界区的代码（也就是请求的资源没有被锁住）●该monitor被其它线程拥有，本线程在Entry Set队列中等待。

（也就是请求的资源正在被其它线程处理，也就是锁住了，要等待锁的解除）在第一种情况下，线程将处于“Runnable”的状态，而第二种情况下，线程DUMP会显示处于“waiting for monitor entry”。

如下所示：临界区的设置，是为了保证其内部的代码执行的原子性和完整性。

但是因为临界区在任何时间只允许线程串行通过，这和我们多线程的程序的初衷是相反的。

如果在多线程的程序中，大量使用synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。

如果在线程DUMP中发现了这个情况，应该审查源码，改进程序。

现在再来看现在线程为什么会进入“Wait Set”。

当线程获得了Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被synchronized 的对象）的wait() 方法，放弃了Monitor，进入“Wait Set”队列。

只有当别的线程在该对象上调用了notify() 或者notifyAll() ，“Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的Monitor，恢复到运行态。

在“Wait Set”中的线程，DUMP中表现为：in Object.wait()，类似于：仔细观察上面的DUMP信息，你会发现它有以下两行：这里需要解释一下，为什么先lock了这个对象，然后又waiting on同一个对象呢？让我们看看这个线程对应的代码：线程的执行中，先用synchronized 获得了这个对象的Monitor（对应于locked <0xef63beb8> ）。

当执行到obj.wait(), 线程即放弃了Monitor的所有权，进入“wait set”队列（对应于waiting on <0xef63beb8> ）。

往往在程序中，会出现多个类似的线程，他们都有相似的DUMP信息。

这也可能是正常的。

比如，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。

这个队列就是lock以及waiting on 的对象。

当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被Notify，当然只有一个线程获得了lock，继续执行，而其它线程继续等待。

2.3 JDK5.0的lock上面提到如果synchronized和monitor机制运用不当，可能会造成多线程程序的性能问题。

在JDK 5.0中，引入了Lock机制，从而使开发者能更灵活的开发高性能的并发多线程程序，可以替代以往JDK中的synchronized和Monitor的机制。

但是，要注意的是，因为Lock类只是一个普通类，JVM无从得知Lock对象的占用情况，所以在线程DUMP中，也不会包含关于Lock的信息，关于死锁等问题，就不如用synchronized的编程方式容易识别。

3.1 死锁在多线程程序的编写中，如果不适当的运用同步机制，则有可能造成程序的死锁，经常表现为程序的停顿，或者不再响应用户的请求。

比如在下面这个示例中，是个较为典型的死锁情况：可以注意到线程1在等待锁<0x22c19f18>，自己锁住了<0x22c19f20>，而线程0正好在等待<0x22c19f20>，而把<0x22c19f18>锁住，从而形成了循环等待，造成死锁。

在JAVA 5中加强了对死锁的检测。

线程Dump中可以直接报告出Java级别的死锁，如下所示：3.2 热锁热锁，也往往是导致系统性能瓶颈的主要因素。

其表现特征为，由于多个线程对临界区，或者锁的竞争，可能出现：●频繁的线程的上下文切换：从操作系统对线程的调度来看，当线程在等待资源而阻塞的时候，操作系统会将之切换出来，放到等待的队列，当线程获得资源之后，调度算法会将这个线程切换进去，放到执行队列中。

●大量的系统调用：因为线程的上下文切换，以及热锁的竞争，或者临界区的频繁的进出，都可能导致大量的系统调用。

●大部分CPU开销用在“系统态”：线程上下文切换，和系统调用，都会导致CPU在“系统态”运行，换而言之，虽然系统很忙碌，但是CPU用在“用户态”的比例较小，应用程序得不到充分的CPU资源。