jstack用於打印出給定的java進程ID或core file或遠程調試服務的Java堆棧信息，如果是在64位機器上，需要指定選項"-J-d64"，
Windows的jstack使用方式只支持以下的這種方式：jstack [-l] pid
如果java程序崩潰生成core文件，jstack工具可以用來獲得core文件的java stack和native stack的信息，從而可以輕松地知道java程序是如何崩潰和在程序何處發生問題。另外，jstack工具還可以附屬到正在運行的java程序中，看到當時運行的java程序的java stack和native stack的信息, 如果現在運行的java程序呈現hung的狀態，jstack是非常有用的。
需要注意的問題:
l 不同的 JAVA虛機的線程 DUMP的創建方法和文件格式是不一樣的，不同的 JVM版本， dump信息也有差別。
l 在實際運行中，往往一次 dump的信息，還不足以確認問題。建議產生三次 dump信息，如果每次 dump都指向同一個問題，我們才確定問題的典型性。
2、命令格式
$jstack [ option ] pid
$jstack [ option ] executable core
$jstack [ option ] [server-id@]remote-hostname-or-IP
參數說明:
pid: java應用程序的進程號,一般可以通過jps來獲得;
executable:產生core dump的java可執行程序;
core:打印出的core文件;
remote-hostname-or-ip:遠程debug服務器的名稱或IP;
server-id: 唯一id,假如一台主機上多個遠程debug服務;
示例:
$ jstack –l 23561
線程分析:
一般情況下，通過jstack輸出的線程信息主要包括：jvm自身線程、用戶線程等。其中jvm線程會在jvm啟動時就會存在。對於用戶線程則是在用戶訪問時才會生成。
l jvm線程：
在線程中，有一些 JVM內部的后台線程，來執行譬如垃圾回收，或者低內存的檢測等等任務，這些線程往往在JVM初始化的時候就存在，如下所示：
| "Attach Listener" daemon prio=10 tid=0x0000000052fb8000 nid=0xb8f waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers: - None destroyJavaVM" prio=10 tid=0x00002aaac1225800 nid=0x7208 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers: - None |
l 用戶級別的線程
還有一類線程是用戶級別的，它會根據用戶請求的不同而發生變化。該類線程的運行情況往往是我們所關注的重點。而且這一部分也是最容易產生死鎖的地方。
| "qtp496432309-42" prio=10 tid=0x00002aaaba2a1800 nid=0x7580 waiting on condition [0x00000000425e9000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000788cfb020> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025) at org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:320) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:479) at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers: - None |
從上述的代碼示例中我們可以看到該用戶線程的以下幾類信息：
Ø 線程的狀態：waiting on condition(等待條件發生)
Ø 線程的調用情況；
Ø 線程對資源的鎖定情況；
線程的狀態分析：
正如我們剛看到的那樣，線程的狀態是一個重要的指標，它會顯示在線程每行結尾的地方。那么線程常見的有哪些狀態呢？線程在什么樣的情況下會進入這種狀態呢？我們能從中發現什么線索？
l Runnable
該狀態表示線程具備所有運行條件，在運行隊列中准備操作系統的調度，或者正在運行。
l Waiton condition
該狀態出現在線程等待某個條件的發生。具體是什么原因，可以結合stacktrace來分析。最常見的情況是線程在等待網絡的讀寫，比如當網絡數據沒有准備好讀時，線程處於這種等待狀態，而一旦有數據准備好讀之后，線程會重新激活，讀取並處理數據。在 Java引入 NIO之前，對於每個網絡連接，都有一個對應的線程來處理網絡的讀寫操作，即使沒有可讀寫的數據，線程仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給操作系統的線程調度也帶來壓力。在 NIO里采用了新的機制，編寫的服務器程序的性能和可擴展性都得到提高。
如果發現有大量的線程都在處在 Wait on condition，從線程 stack看， 正等待網絡讀寫，這可能是一個網絡瓶頸的征兆。因為網絡阻塞導致線程無法執行。一種情況是網絡非常忙，幾乎消耗了所有的帶寬，仍然有大量數據等待網絡讀寫；另一種情況也可能是網絡空閑，但由於路由等問題，導致包無法正常的到達。所以要結合系統的一些性能觀察工具來綜合分析，比如 netstat統計單位時間的發送包的數目，如果很明顯超過了所在網絡帶寬的限制 ; 觀察 cpu的利用率，如果系統態的 CPU時間，相對於用戶態的 CPU時間比例較高；如果程序運行在 Solaris 10平台上，可以用 dtrace工具看系統調用的情況，如果觀察到 read/write的系統調用的次數或者運行時間遙遙領先；這些都指向由於網絡帶寬所限導致的網絡瓶頸。
另外一種出現 Wait on condition的常見情況是該線程在 sleep，等待 sleep的時間到了時候，將被喚醒。
l Waitingfor monitor entry 和 in Object.wait()
在多線程的 JAVA程序中，實現線程之間的同步，就要說說Monitor。Monitor是Java中用以實現線程之間的互斥與協作的主要手段，它可以看成是對象或者 Class的鎖。每一個對象都有，也僅有一個 monitor。下面這個圖，描述了線程和 Monitor之間關系，以及線程的狀態轉換圖：
從圖中可以看出，每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “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，執行臨界區的代碼 。此時線程將處於Runnable狀態；
該 monitor被其它線程擁有，本線程在 Entry Set隊列中等待。此時dump的信息顯示“waiting for monitor entry”。
| "Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000..0xf927bdb8] at testthread.WaitThread.run(WaitThread.java:39) |
臨界區的設置，是為了保證其內部的代碼執行的原子性和完整性。但是因為臨界區在任何時間只允許線程串行通過，這和我們多線程的程序的初衷是相反的。如果在多線程的程序中，大量使用 synchronized，或者不適當的使用了它，會造成大量線程在臨界區的入口等待，造成系統的性能大幅下降。如果在線程 DUMP中發現了這個情況，應該審查源碼，改進程序。
現在我們再來看現在線程為什么會進入 “Wait Set”。當線程獲得了 Monitor，進入了臨界區之后，如果發現線程繼續運行的條件沒有滿足，它則調用對象（一般就是被 synchronized 的對象）的 wait() 方法，放棄了 Monitor，進入 “Wait Set”隊列。只有當別的線程在該對象上調用了 notify() 或者 notifyAll() ， “ Wait Set”隊列中線程才得到機會去競爭，但是只有一個線程獲得對象的Monitor，恢復到運行態。在 “Wait Set”中的線程， DUMP中表現為： in Object.wait()，類似於：
| "Thread-1" prio=10 tid=0x08223250 nid=0xa in Object.wait() [0xef47a000..0xef47aa38] at java.lang.Object.wait(Native Method) - waiting on <0xef63beb8> (a java.util.ArrayList) at java.lang.Object.wait(Object.java:474) at testthread.MyWaitThread.run(MyWaitThread.java:40) - locked <0xef63beb8> (a java.util.ArrayList) at java.lang.Thread.run(Thread.java:595) |
仔細觀察上面的 DUMP信息，你會發現它有以下兩行：
² locked <0xef63beb8> (ajava.util.ArrayList)
² waiting on <0xef63beb8> (ajava.util.ArrayList)
這里需要解釋一下，為什么先 lock了這個對象，然后又 waiting on同一個對象呢？讓我們看看這個線程對應的代碼：
synchronized(obj){
.........
obj.wait();
.........
}
線程的執行中，先用 synchronized 獲得了這個對象的 Monitor（對應於 locked <0xef63beb8> ）。當執行到 obj.wait(), 線程即放棄了 Monitor的所有權，進入 “wait set”隊列（對應於 waiting on<0xef63beb8> ）。
往在你的程序中，會出現多個類似的線程，他們都有相似的 dump也可能是正常的。比如，在程序中有多個服務線程，設計成從一個隊列里面讀取請求數據。這個隊列就是 lock以及 waiting on的對象。當隊列為空的時候，這些線程都會在這個隊列上等待，直到隊列有了數據，這些線程被notify，當然只有一個線程獲得了 lock，繼續執行，而其它線程繼續等待。
參考文獻：