Ragic 部落格
企業電子化的專家 Ragic 教你如何利用各種軟體、
雲端服務讓公司快速升級!
加入 Ragic 企業電子化的行列!
雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
Facebook X 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 帳號註冊

立即科技 Ragic, Inc.
02-7728-8692
info@ragic.com
台北市中正區南昌路二段81號9樓