如何通过线程Dump分析进行调试排错？

Thread Dump介绍 什么是Thread Dump Thread Dump是非常有用的诊断Java应用问题的工具。每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力，虽然各个 Java虚拟机打印的thread dump略有不同，但是 大多都提供了当前活动线程的快照，及JVM中所有Java线程的堆栈跟踪信息，堆栈信息一般包含完整的类名及所执行的方法，如果可能的话还有源代码的行数。 Thread Dump特点 能在各种操作系统下使用； 能在各种Java应用服务器下使用； 能在生产环境下使用而不影响系统的性能； 能将问题直接定位到应用程序的代码行上； Thread Dump抓取 一般当服务器挂起，崩溃或者性能低下时，就需要抓取服务器的线程堆栈（Thread Dump）用于后续的分析。在实际运行中，往往一次 dump的信息，还不足以确认问题。为了反映线程状态的动态变化，需要接连多次做thread dump，每次间隔10-20s，建议至少产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。 操作系统命令获取ThreadDump ps –ef | grep java kill -3 <pid> 注意： 一定要谨慎, 一步不慎就可能让服务器进程被杀死。kill -9 命令会杀死进程。 JVM 自带的工具获取线程堆栈 jps 或 ps –ef | grep java （获取PID） jstack [-l ] <pid> | tee -a jstack.log（获取ThreadDump） Thread Dump分析 Thread Dump信息 头部信息：时间，JVM信息 2011-11-02 19:05:06 Full thread dump Java HotSpot(TM) Server VM (16.3-b01 mixed mode): 线程INFO信息块： 1. "Timer-0" daemon prio=10 tid=0xac190c00 nid=0xaef in Object.wait() [0xae77d000] # 线程名称：Timer-0；线程类型：daemon；优先级: 10，默认是5； # JVM线程id：tid=0xac190c00，JVM内部线程的唯一标识（通过java.lang.Thread.getId()获取，通常用自增方式实现）。 # 对应系统线程id（NativeThread ID）：nid=0xaef，和top命令查看的线程pid对应，不过一个是10进制，一个是16进制。（通过命令：top -H -p pid，可以查看该进程的所有线程信息） # 线程状态：in Object.wait()； # 起始栈地址：[0xae77d000]，对象的内存地址，通过JVM内存查看工具，能够看出线程是在哪儿个对象上等待； 2. java.lang.Thread.State: TIMED_WAITING (on object monitor) 3. at java.lang.Object.wait(Native Method) 4. -waiting on <0xb3885f60> (a java.util.TaskQueue) # 继续wait 5. at java.util.TimerThread.mainLoop(Timer.java:509) 6. -locked <0xb3885f60> (a java.util.TaskQueue) # 已经locked 7. at java.util.TimerThread.run(Timer.java:462) Java thread statck trace：是上面2-7行的信息。到目前为止这是最重要的数据，Java stack trace提供了大部分信息来精确定位问题根源。 Java thread statck trace详解： 堆栈信息应该逆向解读：程序先执行的是第7行，然后是第6行，依次类推。 - locked <0xb3885f60> (a java.util.ArrayList) - waiting on <0xb3885f60> (a java.util.ArrayList) 也就是说对象先上锁，锁住对象0xb3885f60，然后释放该对象锁，进入waiting状态。