学习如何使用 IBM WebSphere Application Server V6.1 中的线程转储工具了解您的系统环境，检查是否发生死锁以及提取信息来帮助避免或解决自己应用程序的死锁情况。
引言
当两个或多个线程彼此形成循环依赖关系时，就出现了死锁。例如，如果线程 A 处于等待线程 B 的等待状态，而同时线程 B 处于等待线程 A 的等待状态，则出现了死锁。一旦形成此情况，线程 A 和线程 B 都不能有任何进展，因为这两个线程现在都无限期地挂起了。为什么会有人创建这种系统？当然，您并不会有意这么做，但由于存在大量线程和复杂事务，因此很容易出现这种情况。
本文将介绍如何使用 IBM WebSphere Application Server V6.1 的线程转储工具来对系统进行检查，以确定是否出现了死锁。为了帮助理解，文中引用和描述了一个真实的示例。在此示例中，企业应用程序在 Web 容器中运行，而 OSGi 包提供对协议的访问。当通信流量突然上升到足够的程度时，在服务器上运行的应用程序将挂起，而且情况极为严重，唯一能够执行的任务就是发出 kill -9 命令来终止进程。本文将介绍如何发现这个典型的死锁情况并加以解决，其中涉及的方法可用于避免或调试您应用程序中类似的条件。
问题
在很多协议中，使用了状态机来管理每个协议连接的状态。这些状态机有时候称为连接有限状态机（Connection Finite State Machines，CFSM）。状态机需要原子操作。这意味着无法在不同的时间对状态机的不同部分进行更新；出现更新时，必须在该操作中对整个状态机进行更新，因此下一个操作应用到新状态，以此类推。为了达到这样的方式，状态机要设计为任何时间只有一个线程能够对状态机执行操作。对状态机的访问方法全部是同步的。希望访问状态机的线程在当前访问状态机的线程完成方法调用前将被阻塞。
在此类示例协议中，任何时间收到、传输数据包或操作超时，都会更改状态。其他条件（如启动、停止和断开连接）也会导致状态机发生变化。状态机的这些输入使其成为了搜索的高风险区，特别是任意数量的线程都可能导致这些事件发生的情况下更是如此。
首次在此应用程序中出现这个问题时，应用服务器锁定情况非常严重，没有出现日志记录，甚至控制台都不能打开。实际上，WebSphere Application Server 进程没有 TCP 通信流量进出。这是死锁的典型症状。CPU 利用率为零，未发生任何事件，也没有请求被接收。唯一可用于进行调试的工具是 WebSphere Application Server 进程的线程转储。
线程转储（或核心文件）是采用以下格式的名称生成的：
javacore.date.time.id.txt
例如： javacore.20070919.204717.27050.txt
在有些情况下，会自动为 Java Virtual Machine (JVM) 创建线程转储，如 WebSphere Application Server 由于普通 stopserver 请求之外的其他方式停止的情况。线程转储还可以通过向 WebSphere Application Server 进程发出信号来触发。例如，为了在 UNIX 环境中生成线程转储，则可以运行此命令：
kill -3 process_id
其中 process_id 是 WebSphere Application Server JVM 的进程 ID。线程转储还可以使用 wsadmin 创建。为了使用 wsadmin 命令提示符强制进行线程转储，请发出以下命令：
wsadmin
wsadmin>set jvm [$AdminControl completeObjectName type=JVM, process=server1,*]
wsadmin>$AdminControl invoke $jvm dumpThreads
这将在 was_profile_root 中创建类似于 javacore.20071012.080508.4252.txt 的文件。
打开线程转储时会看到以下内容：WebSphere Application Server 中每个单线程的堆栈跟踪。但更为重要的是，其中还列出了系统中的所有锁定。很好！
线程转储内容
线程转储是简单的文本文件，可以使用任何文本编辑器打开。您可以在其中找到大量有意义而且有用的信息，具体请参见后面的描述。