Java 线程转储
软件维护是一个枯燥而又有挑战性的工作。只要软件功能符合预期，那么这个工作就是好的。设想一个这样的情景，你的电话半夜也一直在响（这不是一个令人愉快的感受，是吧？）
任何软件系统，无论它当初是被设计的多好，也无论它经历了怎样的质量测试，仍然是有可能出现运行时性能问题。原因可能是内部功能限制或者外部环境影响。软件系统是在某种假定的情景和先入为主的观念之上被建立的。然而，当他们实际运行时，这些假定的情况可能是错误的，由此就会引起系统故障。
企业的J2EE系统通常拥有庞大的用户基数，并且涉及多种系统间的交互，一个常见的运行时问题报告是系统的速度降低或者系统“挂起”。在这样的情形下，常用的故障处理手段就是分析java线程的转储来找到引起系统减速或者挂起的线程。这篇文章就是讨论java的堆栈跟踪信息，匿名线程和怎样读取线程转储的通用方法。
异常和堆栈信息
我们当中的所有人在学习/开发的过程中都会遇到或者曾经遇到过异常。异常是java报告运行时错误的一种方式。异常分为两部分：消息和堆栈信息。消息是告诉你什么出错了。堆栈信息提供了一个涉及到的所有类的完整的调用流程来作为运行时错误的一部分。
下面的例子是一个ArrayIndexOutOfBoundsException（数组下标越界异常）的堆栈信息：
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 4
at Test.run(Test.java:13)
at Test.<init>(Test.java:5)
at Test.main(Test.java:20)
接下来让我们读一下堆栈信息。翻阅异常信息的规则是从第一行（消息行）了解是什么异常，然后接着读下去，来了解调用流程。上面的例子中，调用流程开始于 Test.java的第20行（main方法），然后他调用了Test的构造方法。构造方法在堆栈信息中用<init>表示。然后它跳转到 Test类的run()方法，然后在13行遇到了这个抛出的异常。
从上面的堆栈信息中，我们能够得出结论，在Test.java中，尝试读取的值超过了传递的数组的大小。
java线程转储
java的线程转储可以被定义为JVM中在某一个给定的时刻运行的所有线程的快照。一个线程转储可能包含一个单独的线程或者多个线程。在多线程环境中，比如J2EE应用服务器，将会有许多线程和线程组。每一个线程都有它自己的调用堆栈，在一个给定时刻，表现为一个独立功能。线程转储将会提供JVM中所有线程的堆栈信息，对于特定的线程也会给出更多信息。
java虚拟机进程和java线程
java虚拟机，或者称为JVM，是一个操作系统级别的进程。java线程是JVM进程的子进程或者轻量级进程（Solar中的叫法）。
生成java线程转储
线程转储可以通过向JVM进程发送一个SIGQUIT信号来生成。有两种不同方式来向进程发送这个信号：
在Unix中，使用“kill -3<pid>”命令，pid表示JVM进程的ID。
在Windows中，在JVM运行时按下CTRL+BREAK键。
java线程状态
每一个java线程总是处于其生命周期的四个状态之一。
Runnable-线程正在运行，或者准备好获取CPU时间后运行。JRockit线程转储中把这种状态当做Active。
Waiting on Monitor-线程休眠，或者在等待一个对象，或者等待被其他线程唤醒。在线程对象中调用sleep()方法，或者在一个对象中调用wait()方法时就会有这种情况发生。
举个例子，在WebLogc服务器中，空闲的执行线程处于这种状态，他们会一直等待直到一个Socket reader线程有新的任务才唤醒他们。堆栈信息就会如下所示：
"ExecuteThread: '2' for queue: 'weblogic.admin.RMI'" daemon prio=5 tid=0x1752F040 nid=0x180c in Object.wait() [1887f000..1887fd8c]
at java.lang.Object.wait(Native Method) waiting on <04134D98> (a weblogic.kernel.ExecuteThread)
at java.lang.Object.wait(Object.java:426)
at weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:126)
locked <04134D98> (a weblogic.kernel.ExecuteThread)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:145)
Waiting for Monitor Entry——线程在等待获取一个对象的锁（其他线程可能持有这个同步锁）。这种情况发生在当两个或者更多线程尝试执行一段同步代码时。注意“锁”总是针对于一个对象而不是针对一个单独的方法。
这种情况的线程的简单堆栈信息如下：
"ExecuteThread: '24' for queue: 'DisplayExecuteQueue'" daemon prio=5 tid=0x5541b0 nid=0x3b waiting for monitor entry [49b7f000..49b7fc24]
at weblogic.cluster.replication.ReplicationManager.createSecondary (ReplicationManager.java:908)
- waiting to lock <6c4b9130> (a java.lang.Object)
at weblogic.cluster.replication.ReplicationManager.updateSecondary (ReplicationManager.java:715)
at weblogic.servlet.internal.session.ReplicatedSessionData.syncSession (ReplicatedSessonData.java:459)
- locked <6c408700> (a weblogic.servlet.internal.session.ReplicatedSessionData)
at weblogic.servlet.internal.session.ReplicatedSessionContext.sync (ReplicatedSessionContext.java:134)
- locked <6c408700> (aweblogic.servlet.internal.session.ReplicatedSessionData)
at weblogic.servlet.internal.ServletRequestImpl.syncSession (ServletRequestImpl.java:2418)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:3137)
at weblogic.servlet.internal.ServletRequestImpl.execute (ServletRequestImpl.java:2544)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
某些别的版本的JVM可能不会在堆栈信息中给出对象的ID和锁的信息。同样的状态，在某些JVM版本中可能被称为“MW”。JRockit称之为LOCKED。
分析一个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()。
使用线程转储
在这部分，我将描述几个用例来说明线程转储是非常有用的。
高CPU占用率
诊断
应用程序看起来几乎让CPU的占用率达到了100%，但是系统吞吐量却明显下降。开始于高负载的CPU性能很差。
线程转储
通过所有的线程转储，可以看到一个或多个线程在同一个操作中罢工了。
解决办法
- 为一个特定的调用流程（比如说网页上的form提交），在流程完成之前，生成一系列的线程转储（大约5~7个）
- 查找线程转储中的“runnable”线程。如果每一个线程看起来运行良好（每一个线程调用的方法都不相同），这些线程就是正在处理事务中，而且有可能并不是这次事件的罪魁祸首。如果通过所有的线程转储，发现线程正在执行同一个方法（同样的行号），几乎就可以确定这就是罪魁祸首了。那就可以查看代码，来做代码级别的分析了。你肯定也能从代码中找到解决问题的灵感。
低CPU负载率和很长的响应时间
诊断
这通常在一个高I/O限制的系统处于高负载的时候发生。CPU的占用率很低，只有几个线程在消耗CPU的时间片。然而应用的响应时间却很长。
线程转储
一部分或者全部运行线程看起来就像是在一个I/O操作中罢工了，比如文件读/写或者数据库的操作。
解决方法
了解你系统中的I/O操作。使用缓存以减少应用与数据库之间的交互。
应用/服务宕机
诊断
一个应用或者一个运行这个应用的服务JVM宕机（变得停止响应）
线程转储
- 在获得的所有线程转储中，可以看到所有的运行线程都在同一个操作中罢工了。服务器没有可用的线程，因为没有一个线程能够完成他自己的操作。
- 或许有很多线程在等待一个锁。当一个运行的线程持有一个对象锁不释放，而其他的线程恰好在等待这个对象锁的时候就会发生。
- 检查死锁，通常简单情况下（线程A在等待线程B，同时B也在等待A），JVM通常会检测到死锁。但是，你需要了解在这个时刻锁的状态，以确认这时候是否涉及到一个复杂的死锁了。
- 复查同步方法/代码块，尽可能的将不需要同步的代码移出同步区，以减少同步区的大小。
- 这种问题还有一个可能，就是访问一个远程的资源/组件的响应超时设置的太长。在访问远程对象时设置一个合理的超时时间，这样就能够在远程系统失去响应时抛出一个可以捕获的异常。
- 如果所有的线程在等待一个资源（比如EJB/DB连接），考虑增加这些资源的对象池大小。
对于线程转储分析，既有商业工具也有开源工具。其中有一个叫做Samurial的工具。它是一个轻量级的开源工具，和Java web启动程序一样，也是从命令提示行里启动。想要了解更多信息和文档，请访问http://yusuke.homeip.net/samurai/en/index.html。
总结
在生产环境中维护一个J2EE企业应用是一个艰巨的任务。在生产环境中，随着事务的动态变化，J2EE企业应用的变化可能会表现出运行不稳定。影响一个 J2EE应用的主要因素就是高负载。虽然大多数的系统被设计成可伸缩的，但是环境条件的限制仍然有可能让这些系统变得不响应。
Java线程转储是识别，诊断，检测和解决典型生产问题的绝佳机制。由于应用概览和其他机制的存在，分析java的线程转储将会让我们对常见生产级别的问题有一个明确的早期认识，从而能够节省时间，并让我们的产品应用提供更好的用户体验。