ThreadDump簡介
原本也沒聽說過ThreadDump的概念，直到前幾天，公司的BOPS系統老是OutOfMemory，後來通過ThreadDump，高手們才找到了原因。我在想，ThreadDump肯定是個了不起的東東，於是網上學習瞭解了一下，並自己本機嘗試了將ThreadDump信息打印了出來。
Thread Dump是非常有用的診斷Java應用問題的工具，每一個Java虛擬機都有及時生成顯示所有線程在某一點狀態的thread-dump的能力。雖然各個 Java虛擬機thread dump打印輸出格式上略微有一些不同，但是Thread dumps出來的信息包含線程；線程的運行狀態、標識和調用的堆棧；調用的堆棧包含完整的類名，所執行的方法，如果可能的話還有源代碼的行數。
Thread Dump特點：
能在各種操作系統下使用；能在各種Java應用服務器下使用 ；可以在生產環境下使用而不影響系統的性能；可以將問題直接定位到應用程序的代碼行上 。
Thread Dump能診斷的問題包括：
查找內存泄露，常見的是程序裏load大量的數據到緩存；發現死鎖線程 。
產生ThreadDump堆棧信息的方法：
1. UNIX/Linux
Kill -3 PID
PID通過下面方法獲取
ps -efHl | grep 'java' **. **
2. Windows
直接對MSDOS窗口的程序按Ctrl-break
Sun JVM的常見線程狀態：
對於thread dump信息，主要關注的是線程的狀態和其執行堆棧
線程的狀態一般爲三類
Runnable（R）：當前可以運行的線程
Waiting on monitor（CW）：線程主動wait
Waiting for monitor entry（MW）：線程等鎖
一般關注的都是第一和第三種狀態的線程
Cpu很忙則關注runnable的線程
Cpu閒則關注waiting for monitor entry的線程
如何分析Java虛擬機死鎖
中文資料：
我發現現在網上沒有好好講這個的，少數的幾篇文章都是大談自己的工具，卻沒把方法講清楚。我決定以我以前碰到的case爲例寫一篇來分享。到目前爲止，我認爲分析Java代碼問題的最有效的工具仍然是java thread dump。
原因：
- 任何操作系統平臺下都可以使用。
- 在多數情況下，可以在生產環境中使用。
- 和操作系統提供的工具相比，java thread dump給出的信息是直白的，直接對應到應用代碼。
- 它對被分析的系統干擾很小，因此能反應真實的問題。而其它很多profiling或Instrument工具本身對JVM運行有很大的干擾，經常不能暴露出真正的問題，而且這種工具不能用於生產系統。
我覺得在通常情況下分析Java虛擬機死鎖比分析內存泄漏要容易的多。因爲死鎖發生時，JVM通常處於掛起狀態(hang住了)，thread dump可以給出靜態穩定的信息，查找死鎖只需要查找有問題的線程。而內存泄漏的問題卻很難界定，一個運行的JVM裏有無數對象存在，只有寫程序的人才知道哪些對象是垃圾，而哪些不是，而且對象的引用關係非常複雜，很難得到一份清晰的對象引用圖。
Java虛擬機死鎖發生時，從操作系統上觀察，虛擬機的CPU佔用率爲零，很快會從top或prstat的輸出中消失。這時你就可以收集thread dump了，Unix/Linux 下是kill -3 <JVM pid> ，在Windows下可以在JVM的console窗口上敲Ctrl-Break。根據不同的設置，thread dump會輸出到當前控制檯上或應用服務器的日誌裏。
拿到java thread dump後，你要做的就是查找"waiting for monitor entry"的thread，如果大量thread都在等待給同一個地址上鎖（因爲對於Java，一個對象只有一把鎖），這說明很可能死鎖發生了。比如：
"service-j2ee" prio=5 tid=0x024f1c28 nid=0x125 waiting for monitor entry
[62a3e000..62a3f690]
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.internalGetResource(IASNonS
haredResourcePool.java:625)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - waiting to
lock <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.getResource(IASNonSharedRes
ourcePool.java:520)
................
爲了確定問題，常常需要在隔兩分鐘後再次收集一次thread dump，如果得到的輸出相同，仍然是大量thread都在等待給同一個地址上鎖，那麼肯定是死鎖了。
如何找到當前持有鎖的線程是解決問題的關鍵。方法是搜索thread dump，查找"locked <0x965d8110>"， 找到持有鎖的線程。
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: "Thread-20" daemon prio=5 tid=0x01394f18
nid=0x109 runnable [6716f000..6716fc28]
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.net.SocketInputStream.socketRead0(Native Method)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.net.SocketInputStream.read(SocketInputStream.java:129)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at oracle.net.ns.Packet.receive(Unknown
Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.DataPacket.receive(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.read(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.read(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.read(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:929)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.Ocommoncall.receive(Ocommoncall.java:106)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.TTC7Protocol.logoff(TTC7Protocol.java:396)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f47a0> (a
oracle.jdbc.ttc7.TTC7Protocol)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1518)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f4520> (a
oracle.jdbc.driver.OracleConnection)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.JdbcUrlAllocator.destroyResource(JdbcUrlAllocator.java:122)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.destroyResource(IASNonSharedResourcePool.java:8
72)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.resizePool(IASNonSharedResourcePool.java:1086)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x965d8110> (a
com.sun.enterprise.resource.IASNonSharedResourcePool)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool$Resizer.run(IASNonSharedResourcePool.java:1178)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.util.TimerThread.mainLoop(Timer.java:432)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.util.TimerThread.run(Timer.java:382)
在這個例子裏，持有鎖的線程在等待Oracle返回結果，卻始終等不到響應，因此發生了死鎖。
如果持有鎖的線程還在等待給另一個對象上鎖，那麼還是按上面的辦法順藤摸瓜，直到找到死鎖的根源爲止。
另外，在thread dump裏還會經常看到這樣的線程，它們是等待一個條件而主動放棄鎖的線程。例如：
"Thread-1" daemon prio=5 tid=0x014e97a8 nid=0x80 in Object.wait() [68c6f000..68c6fc28]
at java.lang.Object.wait(Native Method)
- waiting on <0x95b07178> (a java.util.LinkedList)
at com.iplanet.ias.util.collection.BlockingQueue.remove(BlockingQueue.java:258)
- locked <0x95b07178> (a java.util.LinkedList)
at com.iplanet.ias.util.threadpool.FastThreadPool$ThreadPoolThread.run(FastThreadPool.java:241)
at java.lang.Thread.run(Thread.java:534)
有時也會需要分析這類線程，尤其是線程等待的條件。
其實，Java thread dump並不只用於分析死鎖，其它Java應用運行時古怪的行爲都可以用thread dump來分析。
最後，在Java SE 5裏，增加了jstack的工具，也可以獲取thread dump。在Java SE 6裏，通過jconsole的圖形化工具也可以方便地查找涉及object monitors 和java.util.concurrent.locks死鎖。
參考文檔：
http://lzmhehe.javaeye.com/blog/335526
http://sesame.javaeye.com/blog/428012
Thread Dump是非常有用的診斷Java應用問題的工具，每一個Java虛擬機都有及時生成顯示所有線程在某一點狀態的thread-dump的能力。雖然各個 Java虛擬機thread dump打印輸出格式上略微有一些不同，但是Thread dumps出來的信息包含線程；線程的運行狀態、標識和調用的堆棧；調用的堆棧包含完整的類名，所執行的方法，如果可能的話還有源代碼的行數。
Thread Dump特點：
能在各種操作系統下使用；能在各種Java應用服務器下使用 ；可以在生產環境下使用而不影響系統的性能；可以將問題直接定位到應用程序的代碼行上 。
Thread Dump能診斷的問題包括：
查找內存泄露，常見的是程序裏load大量的數據到緩存；發現死鎖線程 。
產生ThreadDump堆棧信息的方法：
1. UNIX/Linux
Kill -3 PID
PID通過下面方法獲取
ps -efHl | grep 'java' **. **
2. Windows
直接對MSDOS窗口的程序按Ctrl-break
Sun JVM的常見線程狀態：
對於thread dump信息，主要關注的是線程的狀態和其執行堆棧
線程的狀態一般爲三類
Runnable（R）：當前可以運行的線程
Waiting on monitor（CW）：線程主動wait
Waiting for monitor entry（MW）：線程等鎖
一般關注的都是第一和第三種狀態的線程
Cpu很忙則關注runnable的線程
Cpu閒則關注waiting for monitor entry的線程
如何分析Java虛擬機死鎖
中文資料：
我發現現在網上沒有好好講這個的，少數的幾篇文章都是大談自己的工具，卻沒把方法講清楚。我決定以我以前碰到的case爲例寫一篇來分享。到目前爲止，我認爲分析Java代碼問題的最有效的工具仍然是java thread dump。
原因：
- 任何操作系統平臺下都可以使用。
- 在多數情況下，可以在生產環境中使用。
- 和操作系統提供的工具相比，java thread dump給出的信息是直白的，直接對應到應用代碼。
- 它對被分析的系統干擾很小，因此能反應真實的問題。而其它很多profiling或Instrument工具本身對JVM運行有很大的干擾，經常不能暴露出真正的問題，而且這種工具不能用於生產系統。
我覺得在通常情況下分析Java虛擬機死鎖比分析內存泄漏要容易的多。因爲死鎖發生時，JVM通常處於掛起狀態(hang住了)，thread dump可以給出靜態穩定的信息，查找死鎖只需要查找有問題的線程。而內存泄漏的問題卻很難界定，一個運行的JVM裏有無數對象存在，只有寫程序的人才知道哪些對象是垃圾，而哪些不是，而且對象的引用關係非常複雜，很難得到一份清晰的對象引用圖。
Java虛擬機死鎖發生時，從操作系統上觀察，虛擬機的CPU佔用率爲零，很快會從top或prstat的輸出中消失。這時你就可以收集thread dump了，Unix/Linux 下是kill -3 <JVM pid> ，在Windows下可以在JVM的console窗口上敲Ctrl-Break。根據不同的設置，thread dump會輸出到當前控制檯上或應用服務器的日誌裏。
拿到java thread dump後，你要做的就是查找"waiting for monitor entry"的thread，如果大量thread都在等待給同一個地址上鎖（因爲對於Java，一個對象只有一把鎖），這說明很可能死鎖發生了。比如：
"service-j2ee" prio=5 tid=0x024f1c28 nid=0x125 waiting for monitor entry
[62a3e000..62a3f690]
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.internalGetResource(IASNonS
haredResourcePool.java:625)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - waiting to
lock <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.getResource(IASNonSharedRes
ourcePool.java:520)
................
爲了確定問題，常常需要在隔兩分鐘後再次收集一次thread dump，如果得到的輸出相同，仍然是大量thread都在等待給同一個地址上鎖，那麼肯定是死鎖了。
如何找到當前持有鎖的線程是解決問題的關鍵。方法是搜索thread dump，查找"locked <0x965d8110>"， 找到持有鎖的線程。
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: "Thread-20" daemon prio=5 tid=0x01394f18
nid=0x109 runnable [6716f000..6716fc28]
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.net.SocketInputStream.socketRead0(Native Method)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.net.SocketInputStream.read(SocketInputStream.java:129)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at oracle.net.ns.Packet.receive(Unknown
Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.DataPacket.receive(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.read(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.read(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.net.ns.NetInputStream.read(Unknown Source)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:929)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.Ocommoncall.receive(Ocommoncall.java:106)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.ttc7.TTC7Protocol.logoff(TTC7Protocol.java:396)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f47a0> (a
oracle.jdbc.ttc7.TTC7Protocol)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1518)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f4520> (a
oracle.jdbc.driver.OracleConnection)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.JdbcUrlAllocator.destroyResource(JdbcUrlAllocator.java:122)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.destroyResource(IASNonSharedResourcePool.java:8
72)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool.resizePool(IASNonSharedResourcePool.java:1086)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x965d8110> (a
com.sun.enterprise.resource.IASNonSharedResourcePool)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
com.sun.enterprise.resource.IASNonSharedResourcePool$Resizer.run(IASNonSharedResourcePool.java:1178)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.util.TimerThread.mainLoop(Timer.java:432)
[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at
java.util.TimerThread.run(Timer.java:382)
在這個例子裏，持有鎖的線程在等待Oracle返回結果，卻始終等不到響應，因此發生了死鎖。
如果持有鎖的線程還在等待給另一個對象上鎖，那麼還是按上面的辦法順藤摸瓜，直到找到死鎖的根源爲止。
另外，在thread dump裏還會經常看到這樣的線程，它們是等待一個條件而主動放棄鎖的線程。例如：
"Thread-1" daemon prio=5 tid=0x014e97a8 nid=0x80 in Object.wait() [68c6f000..68c6fc28]
at java.lang.Object.wait(Native Method)
- waiting on <0x95b07178> (a java.util.LinkedList)
at com.iplanet.ias.util.collection.BlockingQueue.remove(BlockingQueue.java:258)
- locked <0x95b07178> (a java.util.LinkedList)
at com.iplanet.ias.util.threadpool.FastThreadPool$ThreadPoolThread.run(FastThreadPool.java:241)
at java.lang.Thread.run(Thread.java:534)
有時也會需要分析這類線程，尤其是線程等待的條件。
其實，Java thread dump並不只用於分析死鎖，其它Java應用運行時古怪的行爲都可以用thread dump來分析。
最後，在Java SE 5裏，增加了jstack的工具，也可以獲取thread dump。在Java SE 6裏，通過jconsole的圖形化工具也可以方便地查找涉及object monitors 和java.util.concurrent.locks死鎖。
參考文檔：
http://lzmhehe.javaeye.com/blog/335526
http://sesame.javaeye.com/blog/428012