一、Thread Dump介紹

1.1 什么是Thread Dump？

Thread Dump是非常有用的診斷Java應(yīng)用問題的工具。每一個Java虛擬機(jī)都有及時生成所有線程在某一點狀態(tài)的thread-dump的能力，雖然各個 Java虛擬機(jī)打印的thread dump略有不同，但是大多都提供了當(dāng)前活動線程的快照，及JVM中所有Java線程的堆棧跟蹤信息，堆棧信息一般包含完整的類名及所執(zhí)行的方法，如果可能的話還有源代碼的行數(shù)。

1.2 Thread Dump特點

1. 能在各種操作系統(tǒng)下使用

2. 能在各種Java應(yīng)用服務(wù)器下使用

3. 可以在生產(chǎn)環(huán)境下使用而不影響系統(tǒng)的性能

4. 可以將問題直接定位到應(yīng)用程序的代碼行上

1.3 Thread Dump 能診斷的問題

1. 查找內(nèi)存泄露，常見的是程序里load大量的數(shù)據(jù)到緩存；

2. 發(fā)現(xiàn)死鎖線程；

1.4 如何抓取Thread Dump

一般當(dāng)服務(wù)器掛起,崩潰或者性能底下時,就需要抓取服務(wù)器的線程堆棧(Thread Dump)用于后續(xù)的分析. 在實際運行中，往往一次 dump的信息，還不足以確認(rèn)問題。為了反映線程狀態(tài)的動態(tài)變化，需要接連多次做threaddump，每次間隔10-20s，建議至少產(chǎn)生三次 dump信息，如果每次 dump都指向同一個問題，我們才確定問題的典型性。

有很多方式可用于獲取ThreadDump, 下面列出一部分獲取方式：

操作系統(tǒng)命令獲取ThreadDump:

Windows:

1.轉(zhuǎn)向服務(wù)器的標(biāo)準(zhǔn)輸出窗口并按下Control + Break組合鍵, 之后需要將線程堆棧復(fù)制到文件中；

UNIX/ Linux：

首先查找到服務(wù)器的進(jìn)程號(process id), 然后獲取線程堆棧.

1. ps –ef | grep java

2. kill -3 <pid>

注意：一定要謹(jǐn)慎, 一步不慎就可能讓服務(wù)器進(jìn)程被殺死。kill -9 命令會殺死進(jìn)程。

JVM 自帶的工具獲取線程堆棧:

JDK自帶命令行工具獲取PID，再獲取ThreadDump:

1. jps 或 ps –ef|grepjava (獲取PID)

2. jstack [-l ]<pid> | tee -a jstack.log (獲取ThreadDump)

二、java線程的狀態(tài)轉(zhuǎn)換介紹(為后續(xù)分析做準(zhǔn)備)

image.png

2.1 新建狀態(tài)（New）

用new語句創(chuàng)建的線程處于新建狀態(tài)，此時它和其他Java對象一樣，僅僅在堆區(qū)中被分配了內(nèi)存。

2.2 就緒狀態(tài)（Runnable）

當(dāng)一個線程對象創(chuàng)建后，其他線程調(diào)用它的start()方法，該線程就進(jìn)入就緒狀態(tài)，Java虛擬機(jī)會為它創(chuàng)建方法調(diào)用棧和程序計數(shù)器。處于這個狀態(tài)的線程位于可運行池中，等待獲得CPU的使用權(quán)。

2.3 運行狀態(tài)（Running）

處于這個狀態(tài)的線程占用CPU，執(zhí)行程序代碼。只有處于就緒狀態(tài)的線程才有機(jī)會轉(zhuǎn)到運行狀態(tài)。

2.4 阻塞狀態(tài)（Blocked）

阻塞狀態(tài)是指線程因為某些原因放棄CPU，暫時停止運行。當(dāng)線程處于阻塞狀態(tài)時，Java虛擬機(jī)不會給線程分配CPU。直到線程重新進(jìn)入就緒狀態(tài)，它才有機(jī)會轉(zhuǎn)到運行狀態(tài)。

阻塞狀態(tài)可分為以下3種：

1）位于對象等待池中的阻塞狀態(tài)（Blocked in object’s wait pool）：當(dāng)線程處于運行狀態(tài)時，如果執(zhí)行了某個對象的wait()方法，Java虛擬機(jī)就會把線程放到這個對象的等待池中，這涉及到“線程通信”的內(nèi)容。

2）位于對象鎖池中的阻塞狀態(tài)（Blocked in object’s lock pool）：當(dāng)線程處于運行狀態(tài)時，試圖獲得某個對象的同步鎖時，如果該對象的同步鎖已經(jīng)被其他線程占用，Java虛擬機(jī)就會把這個線程放到這個對象的鎖池中，這涉及到“線程同步”的內(nèi)容。

3）其他阻塞狀態(tài)（Otherwise Blocked）：當(dāng)前線程執(zhí)行了sleep()方法，或者調(diào)用了其他線程的join()方法，或者發(fā)出了I/O請求時，就會進(jìn)入這個狀態(tài)。

2.5 死亡狀態(tài)（Dead）

當(dāng)線程退出run()方法時，就進(jìn)入死亡狀態(tài)，該線程結(jié)束生命周期。

三、Thread Dump分析

通過前面1.4部分的方法，獲取Thread Dump信息后，對其進(jìn)行分析；

3.1 首先介紹一下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]
2. java.lang.Thread.State: TIMED_WAITING (on object monitor)
3. atjava.lang.Object.wait(Native Method)
4. -waiting on <0xb3885f60> (a java.util.TaskQueue) ###繼續(xù)wait
5. atjava.util.TimerThread.mainLoop(Timer.java:509)
6. -locked <0xb3885f60> (a java.util.TaskQueue) ###已經(jīng)locked
7. atjava.util.TimerThread.run(Timer.java:462)

第一行：
線程名稱：Timer-0
線程類型：daemon
優(yōu)先級: 10，默認(rèn)是5
jvm線程id：tid=0xac190c00，jvm內(nèi)部線程的唯一標(biāo)識（通過java.lang.Thread.getId()獲取，通常用自增方式實現(xiàn)。）
對應(yīng)系統(tǒng)線程id（NativeThread ID）：nid=0xaef，和top命令查看的線程pid對應(yīng)，不過一個是10進(jìn)制，一個是16進(jìn)制。（通過命令：top -H -p pid，可以查看該進(jìn)程的所有線程信息）
線程狀態(tài)：in Object.wait().
起始棧地址：[0xae77d000]

Java thread statck trace：是上面2-7行的信息。到目前為止這是最重要的數(shù)據(jù)，Java stack trace提供了大部分信息來精確定位問題根源。

對于thread dump信息，主要關(guān)注的是線程的狀態(tài)和其執(zhí)行堆?！，F(xiàn)在針對這兩個重點部分進(jìn)行講解：

1）Java thread statck trace詳解：

堆棧信息應(yīng)該逆向解讀：程序先執(zhí)行的是第7行，然后是第6行，依次類推。

• locked <0xb3885f60> (a java.util.ArrayList)
• waiting on <0xb3885f60> (a java.util.ArrayList)

也就是說對象先上鎖，鎖住對象0xb3885f60，然后釋放該對象鎖，進(jìn)入waiting狀態(tài)。
為啥會出現(xiàn)這樣的情況呢？看看下面的java代碼示例，就會明白：

synchronized(obj) {  
       .........  
       obj.wait();  
       .........  
}  

在堆棧的第一行信息中，進(jìn)一步標(biāo)明了線程在代碼級的狀態(tài)，例如：

java.lang.Thread.State: TIMED_WAITING (parking)

解釋如下：

|blocked|

This thread tried to enter asynchronized block, but the lock was taken by another thread. This thread isblocked until the lock gets released.

|blocked (on thin lock)|

This is the same state asblocked, but the lock in question is a thin lock.

|waiting|

This thread called Object.wait() on an object. The thread will remain there until some other thread sends a notification to that object.

|sleeping|

This thread called java.lang.Thread.sleep().

|parked|

This thread called java.util.concurrent.locks.LockSupport.park().

|suspended|

The thread's execution was suspended by java.lang.Thread.suspend() or a JVMTI agent call.

2) 線程狀態(tài)詳解：

Runnable
The thread is either running or ready to run when it gets its CPU turn.

Wait on condition
The thread is either sleeping or waiting to be notified by another thread.
該狀態(tài)出現(xiàn)在線程等待某個條件的發(fā)生或者sleep。具體是什么原因，可以結(jié)合 stacktrace來分析。最常見的情況是線程在等待網(wǎng)絡(luò)的讀寫，比如當(dāng)網(wǎng)絡(luò)數(shù)據(jù)沒有準(zhǔn)備好讀時，線程處于這種等待狀態(tài)，而一旦有數(shù)據(jù)準(zhǔn)備好讀之后，線程會重新激活，讀取并處理數(shù)據(jù)。在Java引入 New IO之前，對于每個網(wǎng)絡(luò)連接，都有一個對應(yīng)的線程來處理網(wǎng)絡(luò)的讀寫操作，即使沒有可讀寫的數(shù)據(jù)，線程仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給操作系統(tǒng)的線程調(diào)度也帶來壓力。在 New IO里采用了新的機(jī)制，編寫的服務(wù)器程序的性能和可擴(kuò)展性都得到提高。
如果發(fā)現(xiàn)有大量的線程都處在 Wait on condition，從線程 stack看， 正等待網(wǎng)絡(luò)讀寫，這可能是一個網(wǎng)絡(luò)瓶頸的征兆。因為網(wǎng)絡(luò)阻塞導(dǎo)致線程無法執(zhí)行。一種情況是網(wǎng)絡(luò)非常忙，幾乎消耗了所有的帶寬，仍然有大量數(shù)據(jù)等待網(wǎng)絡(luò)讀寫；另一種情況也可能是網(wǎng)絡(luò)空閑，但由于路由等問題，導(dǎo)致包無法正常的到達(dá)。所以要結(jié)合系統(tǒng)的一些性能觀察工具來綜合分析，比如 netstat統(tǒng)計單位時間的發(fā)送包的數(shù)目，看是否很明顯超過了所在網(wǎng)絡(luò)帶寬的限制；觀察cpu的利用率，看系統(tǒng)態(tài)的CPU時間是否明顯大于用戶態(tài)的CPU時間；如果程序運行在 Solaris 10平臺上，可以用dtrace工具看系統(tǒng)調(diào)用的情況，如果觀察到 read/write的系統(tǒng)調(diào)用的次數(shù)或者運行時間遙遙領(lǐng)先；這些都指向由于網(wǎng)絡(luò)帶寬所限導(dǎo)致的網(wǎng)絡(luò)瓶頸。另外一種出現(xiàn) Wait on condition的常見情況是該線程在 sleep，等待 sleep的時間到了，將被喚醒。

Waiting for Monitor Entry and in Object.wait()
The thread is waiting to get the lock for an object (some other thread may be holding the lock). This happens if two or more threads try to execute synchronized code. Note that the lock is always for an object and not for individual methods.
在多線程的 JAVA程序中，實現(xiàn)線程之間的同步，就要說說 Monitor。 Monitor是Java中用以實現(xiàn)線程之間的互斥與協(xié)作的主要手段，它可以看成是對象或者 Class的鎖。每一個對象都有，也僅有一個 monitor。每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “ActiveThread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “Entry Set” 和 “Wait Set”里面等候。在 “Entry Set”中等待的線程狀態(tài)是 “Waiting for monitor entry”，而在 “Wait Set”中等待的線程狀態(tài)是“in Object.wait()”。
先看 “Entry Set”里面的線程。我們稱被 synchronized保護(hù)起來的代碼段為臨界區(qū)。當(dāng)一個線程申請進(jìn)入臨界區(qū)時，它就進(jìn)入了 “Entry Set”隊列。對應(yīng)的 code就像：

synchronized(obj) {
    .........
}

這時有兩種可能性：

1. 該 monitor不被其它線程擁有， Entry Set里面也沒有其它等待線程。本線程即成為相應(yīng)類或者對象的 Monitor的 Owner，執(zhí)行臨界區(qū)的代碼。
2. 該 monitor被其它線程擁有，本線程在 Entry Set隊列中等待。
   在第一種情況下，線程將處于 “Runnable”的狀態(tài)，而第二種情況下，線程 DUMP會顯示處于 “waiting for monitor entry”。

臨界區(qū)的設(shè)置，是為了保證其內(nèi)部的代碼執(zhí)行的原子性和完整性。但是因為臨界區(qū)在任何時間只允許線程串行通過，這和我們多線程的程序的初衷是相反的。如果在多線程的程序中，大量使用 synchronized，或者不適當(dāng)?shù)氖褂昧怂?，會造成大量線程在臨界區(qū)的入口等待，造成系統(tǒng)的性能大幅下降。如果在線程 DUMP中發(fā)現(xiàn)了這個情況，應(yīng)該審查源碼，改進(jìn)程序。

再看“Wait Set”里面的線程。當(dāng)線程獲得了 Monitor，進(jìn)入了臨界區(qū)之后，如果發(fā)現(xiàn)線程繼續(xù)運行的條件沒有滿足，它則調(diào)用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄 Monitor，進(jìn)入 “Wait Set”隊列。只有當(dāng)別的線程在該對象上調(diào)用了 notify() 或者 notifyAll()，“Wait Set”隊列中線程才得到機(jī)會去競爭，但是只有一個線程獲得對象的Monitor，恢復(fù)到運行態(tài)。在 “Wait Set”中的線程， DUMP中表現(xiàn)為： in Object.wait()。

一般，Cpu很忙時，則關(guān)注runnable的線程，Cpu很閑時，則關(guān)注waiting for monitor entry的線程。

3.2 JVM線程介紹

在Thread Dump中，有一些 JVM內(nèi)部的后臺線程，來執(zhí)行譬如垃圾回收，或者低內(nèi)存的檢測等等任務(wù)，這些線程往往在 JVM初始化的時候就存在，如下所示：

HotSpot VM Thread

被HotSpot VM管理的內(nèi)部線程為了完成內(nèi)部本地操作，一般來說不需要擔(dān)心它們，除非CPU很高。

"VM Periodic Task Thread" prio=10tid=0xad909400 nid=0xaed waiting on condition

HotSpot GC Thread

當(dāng)使用HotSpot parallel GC，HotSpot VM默認(rèn)創(chuàng)建一定數(shù)目的GC thread。

"GC task thread#0 (ParallelGC)"prio=10 tid=0xf690b400 nid=0xade runnable
"GC task thread#1 (ParallelGC)"prio=10 tid=0xf690cc00 nid=0xadf runnable
"GC task thread#2 (ParallelGC)"prio=10 tid=0xf690e000 nid=0xae0 runnable
……

當(dāng)面對過多GC，內(nèi)存泄露等問題時，這些是關(guān)鍵的數(shù)據(jù)。使用native id，可以將從OS/Java進(jìn)程觀測到的高CPU與這些線程關(guān)聯(lián)起來。

JNI global references count

JNI global reference是基本的對象引用，從本地代碼到被Java GC管理的Java對象的引用。其角色是阻止仍然被本地代碼使用的對象集合，但在Java代碼中沒有引用。在探測JNI相關(guān)內(nèi)存泄露時，關(guān)注JNI references很重要。如果你的程序直接使用JNI或使用第三方工具，如檢測工具，檢測本地內(nèi)存泄露。

JNI global references: 832

Java Heap utilization view

從jdk1.6開始在thread dump快照底部，可以找到崩潰點的內(nèi)存空間利用情況: YongGen,OldGen和PermGen。目前我測試的系統(tǒng)導(dǎo)出的thread dump，還未見到這一部分內(nèi)容（sun jdk1.6）。以下例子，摘自他人文章：

Heap  
 PSYoungGen      total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)  
  eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)  
  from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)  
  to   space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)  
 PSOldGen        total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)  
  object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)  
 PSPermGen       total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)  
  object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)      

還有一些其他的線程（如下），不一一介紹了，有興趣，可查看文章最后的附件信息。

"Low Memory Detector" daemon prio=10tid=0xad907400 nid=0xaec runnable [0x00000000]
"CompilerThread1" daemon prio=10tid=0xad905400 nid=0xaeb waiting on condition [0x00000000]
"CompilerThread0" daemon prio=10tid=0xad903c00 nid=0xaea waiting on condition [0x00000000]
"Signal Dispatcher" daemon prio=10tid=0xad902400 nid=0xae9 runnable [0x00000000]
"Finalizer" daemon prio=10tid=0xf69eec00 nid=0xae8 in Object.wait() [0xaf17d000]
"Reference Handler" daemon prio=10tid=0xf69ed800 nid=0xae7 in Object.wait() [0xae1e7000]
"VM Thread" prio=10 tid=0xf69e9800nid=0xae6 runnable

四、案例分析：

4.1、使用方案

cpu飆高，load高，響應(yīng)很慢

方案：

• 一個請求過程中多次dump

• 對比多次dump文件的runnable線程，如果執(zhí)行的方法有比較大變化，說明比較正常。如果在執(zhí)行同一個方法，就有一些問題了。

查找占用cpu最多的線程信息

方案：

• 使用命令： top -H -p pid（pid為被測系統(tǒng)的進(jìn)程號），找到導(dǎo)致cpu高的線程id。
  上述Top命令找到的線程id，對應(yīng)著dump thread信息中線程的nid，只不過一個是十進(jìn)制，一個是十六進(jìn)制。

• 在thread dump中，根據(jù)top命令查找的線程id，查找對應(yīng)的線程堆棧信息。

cpu使用率不高但是響應(yīng)很慢

方案：

• 進(jìn)行dump，查看是否有很多thread struck在了i/o、數(shù)據(jù)庫等地方，定位瓶頸原因。

請求無法響應(yīng)

方案：

• 多次dump，對比是否所有的runnable線程都一直在執(zhí)行相同的方法，如果是的，恭喜你，鎖住了！

4.2 案例分析：

1. 死鎖：

死鎖經(jīng)常表現(xiàn)為程序的停頓，或者不再響應(yīng)用戶的請求。從操作系統(tǒng)上觀察，對應(yīng)進(jìn)程的CPU占用率為零，很快會從top或prstat的輸出中消失。

在thread dump中，會看到類似于這樣的信息：

image.png

（圖 1）

image.png

（圖2）

說明：

（圖1）中有一個“Waiting formonitor entry”，可以看出，兩個線程各持有一個鎖，又在等待另一個鎖，很明顯這兩個線程互相持有對方正在等待的鎖。所以造成了死鎖現(xiàn)象；

（圖2）中對死鎖的現(xiàn)象做了說明，可以看到，是“DeadLockTest.java”的39行造成的死鎖現(xiàn)象。這樣就能到相應(yīng)的代碼下去查看，定位問題。

2.熱鎖

熱鎖，也往往是導(dǎo)致系統(tǒng)性能瓶頸的主要因素。其表現(xiàn)特征為：由于多個線程對臨界區(qū)，或者鎖的競爭，可能出現(xiàn)：
* 頻繁的線程的上下文切換：從操作系統(tǒng)對線程的調(diào)度來看，當(dāng)線程在等待資源而阻塞的時候，操作系統(tǒng)會將之切換出來，放到等待的隊列，當(dāng)線程獲得資源之后，調(diào)度算法會將這個線程切換進(jìn)去，放到執(zhí)行隊列中。
* 大量的系統(tǒng)調(diào)用：因為線程的上下文切換，以及熱鎖的競爭，或者臨界區(qū)的頻繁的進(jìn)出，都可能導(dǎo)致大量的系統(tǒng)調(diào)用。
* 大部分CPU開銷用在“系統(tǒng)態(tài) ”：線程上下文切換，和系統(tǒng)調(diào)用，都會導(dǎo)致 CPU在 “系統(tǒng)態(tài) ”運行，換而言之，雖然系統(tǒng)很忙碌，但是 CPU用在 “用戶態(tài) ”的比例較小，應(yīng)用程序得不到充分的 CPU資源。
* 隨著 CPU數(shù)目的增多，系統(tǒng)的性能反而下降。因為CPU數(shù)目多，同時運行的線程就越多，可能就會造成更頻繁的線程上下文切換和系統(tǒng)態(tài)的CPU開銷，從而導(dǎo)致更糟糕的性能。

上面的描述，都是一個 scalability（可擴(kuò)展性）很差的系統(tǒng)的表現(xiàn)。從整體的性能指標(biāo)看，由于線程熱鎖的存在，程序的響應(yīng)時間會變長，吞吐量會降低。

那么，怎么去了解 “熱鎖 ”出現(xiàn)在什么地方呢？一個重要的方法還是結(jié)合操作系統(tǒng)的各種工具觀察系統(tǒng)資源使用狀況，以及收集Java線程的DUMP信息，看線程都阻塞在什么方法上，了解原因，才能找到對應(yīng)的解決方法。

我們曾經(jīng)遇到過這樣的例子，程序運行時，出現(xiàn)了以上指出的各種現(xiàn)象，通過觀察操作系統(tǒng)的資源使用統(tǒng)計信息，以及線程 DUMP信息，確定了程序中熱鎖的存在，并發(fā)現(xiàn)大多數(shù)的線程狀態(tài)都是 Waitingfor monitor entry或者 Wait on monitor，且是阻塞在壓縮和解壓縮的方法上。后來采用第三方的壓縮包 javalib替代 JDK自帶的壓縮包后，系統(tǒng)的性能提高了幾倍。

五、附件：

JVM運行過程中產(chǎn)生的一些比較重要的線程羅列如下：

參考文章：
http://jameswxx.iteye.com/blog/1041173
http://blog.csdn.net/wanyanxgf/article/details/6944987
http://blog.csdn.net/fanshadoop/article/details/8509218
http://www.7dtest.com/site/article-80-1.html
http://blog.csdn.net/a43350860/article/details/8134234
https://weblogs.java.net/blog/mandychung/archive/2005/11/thread_dump_and_1.html

原文鏈接：https://blog.csdn.net/rachel_luo/java/article/details/8920596