一、java线程转储
java的线程转储可以被定义为JVM中在某一个给定的时刻运行的所有线程的快照。一个线程转储可能包含一个单独的线程或者多个线程。在多线程环境中，比如J2EE应用服务器，将会有许多线程和线程组。每一个线程都有它自己的调用堆栈，在一个给定时刻，表现为一个独立功能。线程转储将会提供JVM中所有线程的堆栈信息，对于特定的线程也会给出更多信息。
二、java虚拟机进程和java线程
java虚拟机，或者称为JVM，是一个操作系统级别的进程。java线程是JVM进程的子进程或者轻量级进程（Solar中的叫法）。
三、生成java线程转储
在java程序中有两种常用的方法可以让我们生成线程转储，这些方法对于linux或者Unix操作系统来说是有效的，window情况稍有不同。
1. VisualVM
我们可以使用VisualVM很容易的为任何java程序生成线程转储。只需要在运行的java进程上点右键，选择“Thread Dump”选项来生成。 
2.jstack
java提供了自带的工具jstack，通过这个工具我们可以同样为java进程产生线程转储。通过两个步骤实现
2.1 用“ps -eaf | grep java”命令找到java进程的PID。
2.2 用jstack PID 命令来生成线程转储到控制台，也可以用命令“jstack PID >> mydumps将输出保存到文件中mydumps中。
3. Unix：kill -3 ，输出到了/proc//fd/1
4. Windows：CTRL+BREAK
四、java多线程状态
线程的状态是一个重要的指标，它会显示在线程 Stacktrace的头一行结尾的地方。那么线程常见的有哪些状态呢？线程在什么样的情况下会进入这种状态呢？我们能从中发现什么线索？
1.1 Runnable
该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。
1.2 Wait on condition
该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。
如果发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。
另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。
1.3 Waiting for monitor entry 和 in Object.wait()
在多线程的 JAVA程序中，实现线程之间的同步，就要说说 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”队列。对应的 code就像：
synchronized(obj) {
.........
}
这时有两种可能性：
1）该 monitor不被其它线程拥有， Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码
2）该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。
在第一种情况下，线程将处于 “Runnable”的状态，而第二种情况下，线程 DUMP会显示处于 “waiting for monitor entry”。如下所示：
"Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000..0xf927bdb8]
at testthread.WaitThread.run(WaitThread.java:39)
- waiting to lock <0xef63bf08> (a java.lang.Object)
- locked <0xef63beb8> (a java.util.ArrayList)
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()，类似于：
"Thread-1" prio=10 tid=0x08223250 nid=0xa in Object.wait() [0xef47a000..0xef47aa38]
at java.lang.Object.wait(Native Method)
- waiting on <0xef63beb8> (a java.util.ArrayList)
at java.lang.Object.wait(Object.java:474)
at testthread.MyWaitThread.run(MyWaitThread.java:40)
- locked <0xef63beb8> (a java.util.ArrayList)
at java.lang.Thread.run(Thread.java:595)
仔细观察上面的 DUMP信息，你会发现它有以下两行：
- locked <0xef63beb8> (a java.util.ArrayList)
- waiting on <0xef63beb8> (a java.util.ArrayList)
这里需要解释一下，为什么先 lock了这个对象，然后又 waiting on同一个对象呢？让我们看看这个线程对应的代码：
synchronized(obj) {
.........
obj.wait();
.........
}
线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于 locked <0xef63beb8> ）。当执行到 obj.wait(), 线程即放弃了 Monitor的所有权，进入 “wait set”队列（对应于 waiting on <0xef63beb8> ）。
往往在你的程序中，会出现多个类似的线程，他们都有相似的 DUMP信息。这也可能是正常的。比如，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被 Notify，当然只有一个线程获得了 lock，继续执行，而其它线程继续等待。
五、分析一个Java线程
为了可以理解/分析线程转储，首先要理解线程转储的各个部分。让我们先拿一个简单的线程堆栈为例，并且去了解他的每个部分。
"ExecuteThread: '1' " daemon prio=5 tid=0x628330 nid=0xf runnable [0xe4881000..0xe48819e0]
at com.vantive.vanjavi.VanJavi.VanCreateForm(Native Method)
at com.vantive.vanjavi.VanMain.open(VanMain.java:53)
at jsp_servlet._so.__newServiceOrder.printSOSection( __newServiceOrder.java:3547)
at jsp_servlet._so.__newServiceOrder._jspService (__newServiceOrder.java:5652)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute (ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute (ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) In the above Thread Dump, the interesting part to is the first line. The rest of the stuff is nothing more than a general stack trace. Lets analyze the first line here
Execute Thread : 1 说明了线程的名字
daemon 表明这个线程是一个守护线程
prio=5 线程的优先级 (默认是5)
tid Java的线程Id (这个线程在当前虚拟机中的唯一标识).
nid 线程本地标识. 也就是Solaris中的LWP，线程在操作系统中的标识
runnable 线程的状态 (参考上面的)
[x..y] 当前运行的线程在堆中的地址范围
这个线程转储的剩余部分是调用堆栈。在这个例子中，这个线程（Execute Thread 1）是操作系统守护线程，当前正在执行一个本地方法vanCreateForm()。
六、使用线程转储
在这部分，我将描述几个用例来说明线程转储是非常有用的。
1.高CPU占用率
①诊断
应用程序看起来几乎让CPU的占用率达到了100%，但是系统吞吐量却明显下降。开始于高负载的CPU性能很差。
②线程转储
通过所有的线程转储，可以看到一个或多个线程在同一个操作中罢工了。
③解决办法
- 为一个特定的调用流程（比如说网页上的form提交），在流程完成之前，生成一系列的线程转储（大约5~7个）
- 查找线程转储中的“runnable”线程。如果每一个线程看起来运行良好（每一个线程调用的方法都不相同），这些线程就是正在处理事务中，而且有可能并不是这次事件的罪魁祸首。如果通过所有的线程转储，发现线程正在执行同一个方法（同样的行号），几乎就可以确定这就是罪魁祸首了。那就可以查看代码，来做代码级别的分析了。你肯定也能从代码中找到解决问题的灵感。
2.低CPU负载率和很长的响应时间
①诊断
这通常在一个高I/O限制的系统处于高负载的时候发生。CPU的占用率很低，只有几个线程在消耗CPU的时间片。然而应用的响应时间却很长。
②线程转储
一部分或者全部运行线程看起来就像是在一个I/O操作中罢工了，比如文件读/写或者数据库的操作。
③解决办法
了解你系统中的I/O操作。使用缓存以减少应用与数据库之间的交互。
3.应用/服务宕机
①诊断
一个应用或者一个运行这个应用的服务JVM宕机（变得停止响应）
②线程转储
- 在获得的所有线程转储中，可以看到所有的运行线程都在同一个操作中罢工了。服务器没有可用的线程，因为没有一个线程能够完成他自己的操作。
- 或许有很多线程在等待一个锁。当一个运行的线程持有一个对象锁不释放，而其他的线程恰好在等待这个对象锁的时候就会发生。
③解决办法
- 检查死锁，通常简单情况下（线程A在等待线程B，同时B也在等待A），JVM通常会检测到死锁。但是，你需要了解在这个时刻锁的状态，以确认这时候是否涉及到一个复杂的死锁了。
- 复查同步方法/代码块，尽可能的将不需要同步的代码移出同步区，以减少同步区的大小。
- 这种问题还有一个可能，就是访问一个远程的资源/组件的响应超时设置的太长。在访问远程对象时设置一个合理的超时时间，这样就能够在远程系统失去响应时抛出一个可以捕获的异常。
- 如果所有的线程在等待一个资源（比如EJB/DB连接），考虑增加这些资源的对象池大小。