Java Thread Dump – 系统卡死、CPU 100%等问题的诊断工具

好几次笔者跟一些有满多年Java开发经验的朋友聊到如何去诊断系统为什么会卡住、系统为什么会突然很慢、为什么突然会一直吃掉100%的CPU等问题。 满惊讶的发现，不知道怎么使用thread dump这样的工具来确认系统停在哪一行的人，比率还相当的高！有了这样的工具，可以大大简短系统问题分析的时间。

Thread dump简单的说就是把目前所有JVM里面正在跑、正在等待的thread运行的stack trace通通打印输出来，就跟一般我们在作Exception.printStackTrace打印输出来的东西类似。但是你可以在系统正在运行的状态，去主动叫系统打印输出这样的信息，这时候我们就可以看每一个thread目前正在运行什么东西，有哪些看起来比较可疑，可能是出问题的地方。

首先要怎么样生成thread dump呢？在Linux底下，可以使用” kill -QUIT ”的指令，针对目前正在运行的Java程序process id来下生成thread dump指令。如果在Windows底下，就在正在运行这个java程序的窗口底下，单击下，便会生成 他的thread dump。而thread dump通常会出现在系统的标准引出里面。

要怎么样来研读stack trace呢？以下是一个thread dump的例子：

"Thread-5" (TID:0xee703b78, sys_thread_t:0xee261db8, state:R) prio=5

        mythread.stopper(exec3.java:10)

        mythread.run(exec3.java:16)

    "Thread-4" (TID:0xee703bb8, sys_thread_t:0xee291db8, state:R) prio=5 *current thread*

        mythread.stopper(exec3.java:10)

        mythread.run(exec3.java:16)

    "Finalizer thread" (TID:0xee700220, sys_thread_t:0xee2c1d b8, state:R) prio=1

    "Async Garbage Collector" (TID:0xee700268, sys_thread_t:0 xee2f1db8, state:R) prio=1

    "Idle thread" (TID:0xee7002b0, sys_thread_t:0xee3c1db8, state:R) prio=0

    "Clock" (TID:0xee700088, sys_thread_t:0xee3f1db8, state:CW) prio=12

    "main" (TID:0xee7000b0, sys_thread_t:0x693a0, state:CW) prio=5

        exec3.main(exec3.java:32)

Monitor Cache Dump:

    mythread@EE703BB8/EE74E190: owner "Thread-4" (0xee291db8, 1 entry)

    mythread@EE703B78/EE74E270: owner "Thread-5" (0xee261db8, 1 entry)

     (0x693a0): 

        Waiting to be notified:

            "main" (0x693a0)

Registered Monitor Dump:

    Thread queue lock: 

    Name and type hash table lock: 

    String intern lock: 

    JNI pinning lock: 

    JNI global reference lock: 

    BinClass lock: 

    Class loading lock: 

    Java stack lock: 

    Code rewrite lock: 

    Heap lock: 

    Has finalization queue lock: 

    Finalize me queue lock: 

    Monitor IO lock: 

    Child death monitor: 

    Event monitor: 

    I/O monitor: 

    Alarm monitor: 

        Waiting to be notified:

            "Clock" (0xee3f1db8)

    Sbrk lock: 

    Monitor registry: owner "Thread-4" (0xee291db8, 1 entry)

Thread Alarm Q:

    sys_thread_t 0x693a0   [Timeout in 9997374 ms]

首先我习惯找的是，里面有没有正在运行我们自己写的程序，毕竟错出在自己身上的概率，常常还是比较大一些。接下来可以找有标明*current thread*或是state=R (Runnable)状态的thread，这代表他们正在运行中，系统的问题也可能出现在他们身上。

有时候这样还是没办法来确认问题到底出在哪，毕竟常常比较大规模一点的系统，同时在跑的thread非常多，要猜说问题在哪里可能要猜很久。另外一个会使用的技巧是，在系统正常的时候生成几个thread dump，另外在系统不正常的时候也生成几个thread dump。如此一来我们可以比对一下系统正常与不正常的时候的差异，有哪些thread在某些行的程序特别会出现在有问题的系统状态，而这往往会是问题的 来源。

过去笔者用了这样的方式省去了非常多分析系统问题的时间，无论是找找到底是哪个猪头（自己？）弄了一个跑不完的无限循环，还是被刚刚更新的某个library害的。Thread dump相信会是您分析这类型比较非功能性的系统问题的好工具。