共计 4044 个字符，预计需要花费 11 分钟才能阅读完成。
1 Thread Dump 介绍
1.1 什么是 Thread Dump
Thread Dump 是非常有用的诊断 Java 应用问题的工具。每一个 Java 虚拟机都有及时生成所有线程在某一点状态的 thread-dump 的能力 ，虽然各个 Java 虚拟机打印的 thread dump 略有不同，但是 大多都提供了当前活动线程的快照，及 JVM 中所有 Java 线程的堆栈跟踪信息，堆栈信息一般包含完整的类名及所执行的方法，如果可能的话还有源代码的行数。
1.2 Thread Dump 特点
1.3 Thread Dump 抓取
一般当服务器挂起，崩溃或者性能低下时 ，就需要抓取服务器的线程堆栈（Thread Dump）用于后续的分析。在实际运行中，往往一次 dump 的信息，还不足以确认问题。为了反映线程状态的动态变化， 需要接连多次做 thread dump，每次间隔 10-20s，建议至少产生三次 dump 信息，如果每次 dump 都指向同一个问题，我们才确定问题的典型性。
1. 操作系统命令获取 ThreadDump
注意：
**2.JVM 自带的工具获取线程堆栈
**
**2 Thread Dump 分析
2.1 Thread Dump 信息
1. 头部信息：时间，JVM 信息
**2. 线程 INFO 信息块：
**
3.Java thread statck trace 详解：**
堆栈信息应该逆向解读：程序先执行的是第 7 行，然后是第 6 行，依次类推。
也就是说对象先上锁，锁住对象 0xb3885f60，然后释放该对象锁，进入 waiting 状态。为啥会出现这样的情况呢？看看下面的 java 代码示例，就会明白：
在堆栈的第一行信息中，进一步标明了线程在代码级的状态，例如：
解释如下：
2.2 Thread 状态分析
线程的状态是一个很重要的东西，因此 thread dump 中会显示这些状态，通过对这些状态的分析，能够得出线程的运行状况，进而发现可能存在的问题。线程的状态在 Thread.State 这个枚举类型中定义：
1.NEW：
每一个线程，在堆内存中都有一个对应的 Thread 对象 。Thread t = new Thread(); 当刚刚在堆内存中创建 Thread 对象，还没有调用 t.start() 方法之前，线程就处在 NEW 状态。在这个状态上，线程与普通的 java 对象没有什么区别，就仅仅是一个堆内存中的对象。
2.RUNNABLE：
该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。这个状态的线程比较正常，但如果线程长时间停留在在这个状态就不正常了，这说明线程运行的时间很长（存在性能问题），或者是线程一直得不得执行的机会（存在线程饥饿的问题）。
3.BLOCKED：
线程正在等待获取 java 对象的监视器(也叫内置锁)，即线程正在等待进入由 synchronized 保护的方法或者代码块。synchronized 用来保证原子性，任意时刻最多只能由一个线程进入该临界区域，其他线程只能排队等待。
4.WAITING：
处在该线程的状态，正在等待某个事件的发生，只有特定的条件满足，才能获得执行机会 。而产生这个特定的事件，通常都是另一个线程。也就是说， 如果不发生特定的事件，那么处在该状态的线程一直等待，不能获取执行的机会。比如：
5.TIMED_WAITING：
J.U.C 中很多与线程相关类，都提供了限时版本和不限时版本的 API。TIMED_WAITING 意味着线程调用了限时版本的 API，正在等待时间流逝 。当等待时间过去后，线程一样可以恢复运行。 如果线程进入了 WAITING 状态，一定要特定的事件发生才能恢复运行；而处在 TIMED_WAITING 的线程，如果特定的事件发生或者是时间流逝完毕，都会恢复运行。
6.TERMINATED：
线程执行完毕，执行完 run 方法正常返回，或者抛出了运行时异常而结束，线程都会停留在这个状态。这个时候线程只剩下 Thread 对象了，没有什么用了。
2.3 关键状态分析
1.Wait on condition：_The thread is either sleeping or waiting to be notified by another thread._
该状态说明它在等待另一个条件的发生，来把自己唤醒，或者干脆它是调用了 sleep(n)。
此时线程状态大致为以下几种：
2.Waiting for Monitor Entry 和 in Object.wait()：_The thread is waiting to get the lock for an object (some other thread may be holding the lock). This happens if two or more threads try to execute synchronized code. Note that the lock is always for an object and not for individual methods._
在多线程的 JAVA 程序中，实现线程之间的同步，就要说说 Monitor。Monitor 是 Java 中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class 的锁。每一个对象都有，也仅有一个 Monitor。下面这个图，描述了线程和 Monitor 之间关系，以及线程的状态转换图：
如上图，每个 Monitor 在某个时刻，只能被一个线程拥有，该线程就是“ActiveThread”，而其它线程都是“Waiting Thread”，分别在两个队列“Entry Set”和“Wait Set”里等候。在“Entry Set”中等待的线程状态是“Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是“in Object.wait()”。
先看“Entry Set”里面的线程 。我们称被 synchronized 保护起来的代码段为临界区。 当一个线程申请进入临界区时，它就进入了“Entry Set”队列。对应的 code 就像：
这时有两种可能性：
** 在第一种情况下，线程将处于“Runnable”的状态，而第二种情况下，线程 DUMP 会显示处于“waiting for monitor entry”。如下：
**
**at java.lang.Thread.run(Thread.java:595)
**
临界区的设置，是为了保证其内部的代码执行的原子性和完整性 。但是因为临界区在任何时间只允许线程串行通过，这和我们多线程的程序的初衷是相反的。 如果在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在线程 DUMP 中发现了这个情况，应该审查源码，改进程序。
再看“Wait Set”里面的线程 。当线程获得了 Monitor，进入了临界区之后， 如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃 Monitor，进入“Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll()，“Wait Set”队列中线程才得到机会去竞争 ，但是只有一个线程获得对象的 Monitor，恢复到运行态。 在“Wait Set”中的线程，DUMP 中表现为：in Object.wait()。如下：
综上，一般 CPU 很忙时，则关注 runnable 的线程，CPU 很闲时，则关注 waiting for monitor entry 的线程。
3.JDK 5.0 的 Lock
上面提到如果 synchronized 和 monitor 机制运用不当，可能会造成多线程程序的性能问题。在 JDK 5.0 中，引入了 Lock 机制，从而使开发者能更灵活的开发高性能的并发多线程程序，可以替代以往 JDK 中的 synchronized 和 Monitor 的 机制。但是，要注意的是，因为 Lock 类只是一个普通类，JVM 无从得知 Lock 对象的占用情况，所以在线程 DUMP 中，也不会包含关于 Lock 的信息，关于死锁等问题，就不如用 synchronized 的编程方式容易识别。
2.4 关键状态示例
显示 BLOCKED 状态
先获取 object 的线程会执行 5 分钟，这 5 分钟内会一直持有 object 的监视器，另一个线程无法执行处在 BLOCKED 状态：
通过 thread dump 可以看到：t2 线程确实处在 BLOCKED (on object monitor)。waiting for monitor entry 等待进入 synchronized 保护的区域。
2. 显示 WAITING 状态
可以发现 t1 和 t2 都处在 WAITING (on object monitor)，进入等待状态的原因是调用了 in Object.wait()。通过 J.U.C 包下的锁和条件队列，也是这个效果，大家可以自己实践下。
3. 显示 TIMED_WAITING 状态
可以看到 t1 和 t2 线程都处在 java.lang.Thread.State: TIMED_WAITING (parking)，这个 parking 代表是调用的 JUC 下的工具类，而不是 java 默认的监视器。
3 案例分析
3.1 问题场景
1.CPU 飙高，load 高，响应很慢
**2. 查找占用 CPU 最多的线程
**
3.CPU 使用率不高但是响应很慢**
4. 请求无法响应 **
3.2 死锁
死锁经常表现为程序的停顿，或者不再响应用户的请求。从操作系统上观察，对应进程的 CPU 占用率为零，很快会从 top 或 prstat 的输出中消失。
比如在下面这个示例中，是个较为典型的死锁情况：
在 JAVA 5 中加强了对死锁的检测。线程 Dump 中可以直接报告出 Java 级别的死锁，如下所示：
3.3 热锁
热锁，也往往是导致系统性能瓶颈的主要因素。其表现特征为：由于多个线程对临界区，或者锁的竞争，可能出现：
上面的描述，都是一个 scalability（可扩展性）很差的系统的表现。从整体的性能指标看，由于线程热锁的存在，程序的响应时间会变长，吞吐量会降低。
那么，怎么去了解“热锁”出现在什么地方呢？
4 JVM 重要线程
JVM 运行过程中产生的一些比较重要的线程罗列如下：