Ragic 博客
企业电子化的专家 Ragic 教你如何利用各种软件、
云服务让公司快速升级!
加入 Ragic 企业电子化的行列!
云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic
Facebook Twitter YouTube
云数据库
博客
关于Ragic
云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic

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

作者:Jeff Kuo

好几次笔者跟一些有满多年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相信会是您分析这类型比较非功能性的系统问题的好工具。

博客背后使用 Ragic! : 最强大的 No Code 企业电子化工具
把数据放在Excel上不只是拖累团队的行政效率,他也很容易出错并且无法进行任何内控。
当您的团队成长时,使用Excel管理数据就会越来越痛苦。
创建你们的第一个云数据库!

马上登记
免费试用 Ragic!

用 Google 帐号登记

北京立即科技有限公司
京ICP备2022003680号