最近在做性能測試，需要對線程堆棧進行分析，在網上收集了一些資料，學習完後，將相關知識整理在一起，輸出文章如下。

一、Thread Dump介紹

1.1什麽是Thread Dump？

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

1.2 Thread Dump特點

1. 能在各種操作系統下使用

2. 能在各種Java應用服務器下使用

3. 可以在生產環境下使用而不影響系統的性能

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

1.3 Thread Dump 能診斷的問題

1. 查找內存泄露，常見的是程序裏load大量的數據到緩存；

2. 發現死鎖線程；

1.4如何抓取Thread Dump

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

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

操作系統命令獲取ThreadDump:

Windows:

1.轉向服務器的標準輸出窗口並按下Control + Break組合鍵, 之後需要將線程堆棧復制到文件中；

UNIX/ Linux：

首先查找到服務器的進程號(process id), 然後獲取線程堆棧.

1. ps –ef | grep java

2. kill -3 <pid>

註意：一定要謹慎, 一步不慎就可能讓服務器進程被殺死。kill -9 命令會殺死進程。

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

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

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

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

二、java線程的狀態轉換介紹(為後續分析做準備)

2.1 新建狀態（New）

用new語句創建的線程處於新建狀態，此時它和其他Java對象一樣，僅僅在堆區中被分配了內存。

2.2 就緒狀態（Runnable）

當一個線程對象創建後，其他線程調用它的start()方法，該線程就進入就緒狀態，Java虛擬機會為它創建方法調用棧和程序計數器。處於這個狀態的線程位於可運行池中，等待獲得CPU的使用權。

2.3 運行狀態（Running）

處於這個狀態的線程占用CPU，執行程序代碼。只有處於就緒狀態的線程才有機會轉到運行狀態。

2.4 阻塞狀態（Blocked）

阻塞狀態是指線程因為某些原因放棄CPU，暫時停止運行。當線程處於阻塞狀態時，Java虛擬機不會給線程分配CPU。直到線程重新進入就緒狀態，它才有機會轉到運行狀態。

阻塞狀態可分為以下3種：

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

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

3）其他阻塞狀態（Otherwise Blocked）：當前線程執行了sleep()方法，或者調用了其他線程的join()方法，或者發出了I/O請求時，就會進入這個狀態。

2.5 死亡狀態（Dead）

當線程退出run()方法時，就進入死亡狀態，該線程結束生命周期。

三、Thread Dump分析

通過前面1.4部分的方法，獲取Thread Dump信息後，對其進行分析；

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=10tid=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) ###繼續wait

5. atjava.util.TimerThread.mainLoop(Timer.java:509)

6. -locked <0xb3885f60> (a java.util.TaskQueue) ###已經locked

7. atjava.util.TimerThread.run(Timer.java:462)

* 線程名稱：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]

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

對於thread dump信息，主要關註的是線程的狀態和其執行堆棧。現在針對這兩個重點部分進行講解：

1）Java thread statck trace詳解：

堆棧信息應該逆向解讀：程序先執行的是第7行，然後是第6行，依次類推。

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

也就是說對象先上鎖，鎖住對象0xb3885f60，然後釋放該對象鎖，進入waiting狀態。

為啥會出現這樣的情況呢？看看下面的java代碼示例，就會明白：

synchronized(obj) {

.........

obj.wait();

.........

}

在堆棧的第一行信息中，進一步標明了線程在代碼級的狀態，例如：

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 calledObject.wait() on an object. The thread will remain there until some otherthread sends a notification to that object.

|sleeping|

This thread calledjava.lang.Thread.sleep().

|parked|

This thread calledjava.util.concurrent.locks.LockSupport.park().

|suspended|

The thread‘s execution wassuspended by java.lang.Thread.suspend() or a JVMTI agent call.

2) 線程狀態詳解：

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._
該狀態出現在線程等待某個條件的發生或者sleep。具體是什麽原因，可以結合 stacktrace來分析。最常見的情況是線程在等待網絡的讀寫，比如當網絡數據沒有準備好讀時，線程處於這種等待狀態，而一旦有數據準備好讀之後，線程會重新激活，讀取並處理數據。在Java引入 New IO之前，對於每個網絡連接，都有一個對應的線程來處理網絡的讀寫操作，即使沒有可讀寫的數據，線程仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給操作系統的線程調度也帶來壓力。在 New IO裏采用了新的機制，編寫的服務器程序的性能和可擴展性都得到提高。
如果發現有大量的線程都處在 Wait on condition，從線程 stack看， 正等待網絡讀寫，這可能是一個網絡瓶頸的征兆。因為網絡阻塞導致線程無法執行。一種情況是網絡非常忙，幾乎消耗了所有的帶寬，仍然有大量數據等待網絡讀寫；另一種情況也可能是網絡空閑，但由於路由等問題，導致包無法正常的到達。所以要結合系統的一些性能觀察工具來綜合分析，比如 netstat統計單位時間的發送包的數目，看是否很明顯超過了所在網絡帶寬的限制；觀察cpu的利用率，看系統態的CPU時間是否明顯大於用戶態的CPU時間；如果程序運行在
Solaris 10平臺上，可以用dtrace工具看系統調用的情況，如果觀察到 read/write的系統調用的次數或者運行時間遙遙領先；這些都指向由於網絡帶寬所限導致的網絡瓶頸。另外一種出現 Wait on condition的常見情況是該線程在 sleep，等待 sleep的時間到了，將被喚醒。

Waiting for Monitor Entry and in Object.wait()

_The thread is waiting to getthe lock for an object (some other thread may be holding the lock). Thishappens if two or more threads try to execute synchronized code. Note that thelock is always for an object and not for individual methods._

在多線程的 JAVA程序中，實現線程之間的同步，就要說說 Monitor。 Monitor是Java中用以實現線程之間的互斥與協作的主要手段，它可以看成是對象或者 Class的鎖。每一個對象都有，也僅有一個 monitor。每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “ActiveThread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”裏面等候。在 “Entry Set”中等待的線程狀態是 “Waiting
for monitorentry”，而在 “Wait Set”中等待的線程狀態是“in Object.wait()”。
先看 “Entry Set”裏面的線程。我們稱被 synchronized保護起來的代碼段為臨界區。當一個線程申請進入臨界區時，它就進入了 “Entry Set”隊列。對應的 code就像：
synchronized(obj) {
.........
}
這時有兩種可能性：
該 monitor不被其它線程擁有， Entry Set裏面也沒有其它等待線程。本線程即成為相應類或者對象的 Monitor的 Owner，執行臨界區的代碼。
該 monitor被其它線程擁有，本線程在 Entry Set隊列中等待。
在第一種情況下，線程將處於 “Runnable”的狀態，而第二種情況下，線程 DUMP會顯示處於 “waiting for monitor entry”。

臨界區的設置，是為了保證其內部的代碼執行的原子性和完整性。但是因為臨界區在任何時間只允許線程串行通過，這和我們多線程的程序的初衷是相反的。如果在多線程的程序中，大量使用 synchronized，或者不適當的使用了它，會造成大量線程在臨界區的入口等待，造成系統的性能大幅下降。如果在線程 DUMP中發現了這個情況，應該審查源碼，改進程序。

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

一般，Cpu很忙時，則關註runnable的線程，Cpu很閑時，則關註waiting for monitor entry的線程。

3.2 JVM線程介紹

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

HotSpot VM Thread

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

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

HotSpot GC Thread

當使用HotSpot parallel GC，HotSpot VM默認創建一定數目的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

……

當面對過多GC，內存泄露等問題時，這些是關鍵的數據。使用native id，可以將從OS/Java進程觀測到的高CPU與這些線程關聯起來。

JNI global references count

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

JNI global references: 832

Java Heap utilization view

從jdk1.6開始在thread dump快照底部，可以找到崩潰點的內存空間利用情況:YongGen,OldGen和PermGen。目前我測試的系統導出的thread dump，還未見到這一部分內容（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高，響應很慢

方案：
* 一個請求過程中多次dump

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

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

方案：
* 使用命令： top -H -p pid（pid為被測系統的進程號），找到導致cpu高的線程id。

上述Top命令找到的線程id，對應著dump thread信息中線程的nid，只不過一個是十進制，一個是十六進制。

* 在thread dump中，根據top命令查找的線程id，查找對應的線程堆棧信息。

cpu使用率不高但是響應很慢

方案：
* 進行dump，查看是否有很多thread struck在了i/o、數據庫等地方，定位瓶頸原因。

請求無法響應

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

4.2 案例分析：

1.死鎖：

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

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

（圖 1）

（圖2）

說明：

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

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

2.熱鎖

熱鎖，也往往是導致系統性能瓶頸的主要因素。其表現特征為：由於多個線程對臨界區，或者鎖的競爭，可能出現：
* 頻繁的線程的上下文切換：從操作系統對線程的調度來看，當線程在等待資源而阻塞的時候，操作系統會將之切換出來，放到等待的隊列，當線程獲得資源之後，調度算法會將這個線程切換進去，放到執行隊列中。
* 大量的系統調用：因為線程的上下文切換，以及熱鎖的競爭，或者臨界區的頻繁的進出，都可能導致大量的系統調用。
* 大部分CPU開銷用在“系統態 ”：線程上下文切換，和系統調用，都會導致 CPU在 “系統態 ”運行，換而言之，雖然系統很忙碌，但是 CPU用在 “用戶態 ”的比例較小，應用程序得不到充分的 CPU資源。
* 隨著 CPU數目的增多，系統的性能反而下降。因為CPU數目多，同時運行的線程就越多，可能就會造成更頻繁的線程上下文切換和系統態的CPU開銷，從而導致更糟糕的性能。
上面的描述，都是一個 scalability（可擴展性）很差的系統的表現。從整體的性能指標看，由於線程熱鎖的存在，程序的響應時間會變長，吞吐量會降低。
那麽，怎麽去了解 “熱鎖 ”出現在什麽地方呢？一個重要的方法還是結合操作系統的各種工具觀察系統資源使用狀況，以及收集Java線程的DUMP信息，看線程都阻塞在什麽方法上，了解原因，才能找到對應的解決方法。
我們曾經遇到過這樣的例子，程序運行時，出現了以上指出的各種現象，通過觀察操作系統的資源使用統計信息，以及線程 DUMP信息，確定了程序中熱鎖的存在，並發現大多數的線程狀態都是 Waitingfor monitor entry或者 Wait on monitor，且是阻塞在壓縮和解壓縮的方法上。後來采用第三方的壓縮包 javalib替代 JDK自帶的壓縮包後，系統的性能提高了幾倍。

五、附件：

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

性能分析之– JAVA Thread Dump 分析