【JVM性能调优】jstack和线程dump分析
一、幾個概念：
1、jstack命令的語法格式：jstack <pid>，可用于查看java進程id。
2、Dump文件：Dump文件是進程的內存鏡像。可以把程序的執行狀態通過調試器保存到dump文件中。Dump文件是用來給驅動程序編寫人員調試驅動程序用的，這種文件必須用專門的工具軟件打開，比如使用Windbg。
在Windbg中可以通過.dump命令保存進程的dump文件。比如下面的命令把當前進程的鏡像保存為c:\testdump.dmp文件：.dump /ma c:\testdump.dmp。
其中、ma參數表示dump文件應該包含進程的完整信息，包括整個用戶態的內存，這樣dump文件尺寸會比較大，信息非常全面。如果不是用、ma參數，保存下來的dump文件只包含了部分重要資料，比如寄存器和線程棧空間，文件尺寸會比較小，無法分析所有的數據。
3、java線程Dump：線程dump是非常有用的診斷java應用問題的工具，每一個java虛擬機都有及時生成顯示所有線程在某一點狀態的線程dump的能力。雖然各個java虛擬機線程dump打印輸出格式上略微有一些不同，但是線程dump出來的信息包含線程基本信息；線程的運行狀態、標識和調用的堆棧；調用的堆棧包含完整的類名，所執行的方法，如果可能的話還有源代碼的行數。
JVM中的許多問題都可以使用線程dump文件來進行診斷，其中比較典型的包括線程阻塞，CPU使用率過高，JVM Crash，堆內存不足和類裝載等問題。
一般情況下，通過jstack輸出的線程信息主要包括：jvm自身線程、用戶線程等。其中jvm線程會在jvm啟動時就會存在。對于用戶線程則是在用戶訪問時才會生成。
或者可以使用一下命令將線程信息存入文件中：#jstack -l pid > jstack.log
其中標注daemon字樣的是后臺線程。以上的用戶線程中包括：
1、線程的一些基本信息：名稱、優先級及id
2、線程狀態：waiting on condition等
3、線程的調用棧
4、線程鎖住的資源：locked<0x3f63d600>
二、Monitor（監視器）
??在多線程的java程序中，實現線程之間的同步，就要說說Monitor。Monitor是java中用以實現線程之間的互斥與協作的主要手段，它可以看成是對象或者Class的鎖。每一個對象都有，也僅有一個Monitor。下面這個圖描述了線程和Monitor之間的關系，以及線程的狀態轉換圖：
1、進入區（Entry Set）：表示線程通過synchronized要求獲取對象的鎖。如果對象未被鎖住，則進入擁有者；否則在進入區等待。一旦對象鎖被其他線程釋放，立即參與競爭。
2、擁有者（The Owner）：表示某一線程成功競爭到對象鎖。
3、等待區（Wait Set）：表示線程通過對象的wait方法釋放對象的鎖，并在等待區等待被喚醒。
??從圖中可以看出，一個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的線程狀態是 “Waiting for monitor entry”，而在“Wait Set”中等待的線程狀態是 “in Object.wait()”。 先看 “Entry Set”里面的線程。我們稱被 synchronized保護起來的代碼段為臨界區。當一個線程申請進入臨界區時，它就進入了 “Entry Set”隊列。對應的 code就像：
synchronized(obj){…… }三、調用修飾：
??表示線程在方法調用時額外的重要操作。線程dump分析的重要信息。修飾上方的方法調用。
1、locked<地址>目標：使用synchronized申請對象鎖成功，監視器的擁有者；
2、waiting to lock<地址>目標：使用synchronized申請對象鎖未成功，在進入區等待；
3、waiting on<地址>目標：使用synchronized申請對象鎖成功后，調用了wait方法，進入對象的等待區等待。在調用棧頂出線，線程狀態為WAITING或TIMED_WAITING；
4、parking to wait for<地址>目標：park是基本的線程阻塞原語，不通過監視器在對象上阻塞。隨concurrent包出現的新的機制，與synchronized體系不同；
四、線程狀態
??想要通過jstack命令來分析線程的情況的話，首先要知道線程都有哪些狀態，下面這些狀態是我們使用jstack命令查看線程堆棧信息時可能會看到的線程的幾種狀態：
1、NEW,未啟動的。不會出現在Dump中。
2、RUNNABLE,在虛擬機內執行的。
3、BLOCKED,受阻塞并等待監視器鎖。
4、WATING,無限期等待另一個線程執行特定操作。
5、TIMED_WATING,有時限的等待另一個線程的特定操作。
6、TERMINATED,已退出的。
五、線程動作：
線程狀態產生的原因：
1、runnable：狀態一般為RUNNABLE，表示線程具備所有運行條件，在運行隊列中準備操作系統的調度，或者正在運行。
2、in Object.wait()：等待區等待，狀態為WAITING或TIMED_WAITING。
3、waiting for monitor entry：進入區等待，狀態為BLOCKED。
4、waiting on condition：等待去等待，被park。
5、sleeping：休眠的線程，調用了Thread.sleep()。
??Wait on condition 該狀態出現在線程等待某個條件的發生。具體是什么原因，可以結合 stacktrace來分析。 最常見的情況就是線程處于sleep狀態，等待被喚醒。 常見的情況還有等待網絡IO：在java引入nio之前，對于每個網絡連接，都有一個對應的線程來處理網絡的讀寫操作，即使沒有可讀寫的數據，線程仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給操作系統的線程調度也帶來壓力。
??在 NIO里采用了新的機制，編寫的服務器程序的性能和可擴展性都得到提高。 正等待網絡讀寫，這可能是一個網絡瓶頸的征兆。因為網絡阻塞導致線程無法執行。一種情況是網絡非常忙，幾 乎消耗了所有的帶寬，仍然有大量數據等待網絡讀 寫；另一種情況也可能是網絡空閑，但由于路由等問題，導致包無法正常的到達。所以要結合系統的一些性能觀察工具來綜合分析，比如 netstat統計單位時間的發送包的數目，如果很明顯超過了所在網絡帶寬的限制 ; 觀察 cpu的利用率，如果系統態的 CPU時間，相對于用戶態的 CPU時間比例較高；如果程序運行在 Solaris 10平臺上，可以用 dtrace工具看系統調用的情況，如果觀察到 read/write的系統調用的次數或者運行時間遙遙領先；這些都指向由于網絡帶寬所限導致的網絡瓶頸。
六、線程分析
1. JVM 線程
??在線程中，有一些 JVM內部的后臺線程，來執行譬如垃圾回收，或者低內存的檢測等等任務，這些線程往往在 JVM初始化的時候就存在，如下所示：
我們更多的是要觀察用戶級別的線程，如下所示：
1. "Thread-1" prio=10 tid=0x08223860 nid=0xa waiting on condition [0xef47a000..0xef47ac38] 2. 3. at java.lang.Thread.sleep(Native Method) 4. 5. at testthread.MySleepingThread.method2(MySleepingThread.java:53) 6. 7. - locked <0xef63d600> (a testthread.MySleepingThread) 8. 9. at testthread.MySleepingThread.run(MySleepingThread.java:35) 10. 11. at java.lang.Thread.run(Thread.java:595) </span>我們能看到：
* 線程的狀態： waiting on condition
* 線程的調用棧
* 線程的當前鎖住的資源： <0xef63d600>
2. 線程的狀態分析
??正如我們剛看到的那樣，線程的狀態是一個重要的指標，它會顯示在線程 Stacktrace的頭一行結尾的地方。那么線程常見的有哪些狀態呢？線程在什么樣的情況下會進入這種狀態呢？我們能從中發現什么線索？
2.1 Runnable
??該狀態表示線程具備所有運行條件，在運行隊列中準備操作系統的調度，或者正在運行。
2.2 Wait on condition
??該狀態出現在線程等待某個條件的發生。具體是什么原因，可以結合 stacktrace來分析。最常見的情況是線程在等待網絡的讀寫，比如當網絡數據沒有準備好讀時，線程處于這種等待狀態，而一旦有數據準備好讀之后，線程會重新激活，讀取并處理數據。在 Java引入 NewIO之前，對于每個網絡連接，都有一個對應的線程來處理網絡的讀寫操作，即使沒有可讀寫的數據，線程仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給操作系統的線程調度也帶來壓力。在 NewIO里采用了新的機制，編寫的服務器程序的性能和可擴展性都得到提高。
??如果發現有大量的線程都在處在 Wait on condition，從線程 stack看， 正等待網絡讀寫，這可能是一個網絡瓶頸的征兆。因為網絡阻塞導致線程無法執行。一種情況是網絡非常忙，幾 乎消耗了所有的帶寬，仍然有大量數據等待網絡讀 寫；另一種情況也可能是網絡空閑，但由于路由等問題，導致包無法正常的到達。所以要結合系統的一些性能觀察工具來綜合分析，比如 netstat統計單位時間的發送包的數目，如果很明顯超過了所在網絡帶寬的限制 ; 觀察 cpu的利用率，如果系統態的 CPU時間，相對于用戶態的 CPU時間比例較高；如果程序運行在 Solaris 10平臺上，可以用 dtrace工具看系統調用的情況，如果觀察到 read/write的系統調用的次數或者運行時間遙遙領先；這些都指向由于網絡帶寬所限導致的網絡瓶頸。另外一種出現 Wait on condition的常見情況是該線程在 sleep，等待 sleep的時間到了時候，將被喚醒。
2.3 Waiting for monitor entry 和 in Object.wait()
??在多線程的 JAVA程序中，實現線程之間的同步，就要說說 Monitor。 Monitor是 Java中用以實現線程之間的互斥與協作的主要手段，它可以看成是對象或者 Class的鎖。每一個對象都有，也僅有一個 monitor。每個 Monitor在某個時刻，只能被一個線程擁有，該線程就是 “Active Thread”，而其它線程都是 “Waiting Thread”，分別在兩個隊列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的線程狀態是 “Waiting for monitor entry”，而在 “Wait Set”中等待的線程狀態是 “in Object.wait()”。
先看 “Entry Set”里面的線程。我們稱被 synchronized保護起來的代碼段為臨界區。當一個線程申請進入臨界區時，它就進入了 “Entry Set”隊列。對應的 code就像：
這時有兩種可能性：
1、該 monitor不被其它線程擁有， Entry Set里面也沒有其它等待線程。本線程即成為相應類或者對象的 Monitor的 Owner，執行臨界區的代碼
2、該 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()，類似于：
仔細觀察上面的 DUMP信息，你會發現它有以下兩行：
- locked <0xef63beb8> (a java.util.ArrayList)
- waiting on <0xef63beb8> (a java.util.ArrayList)
??這里需要解釋一下，為什么先 lock了這個對象，然后又 waiting on同一個對象呢？讓我們看看這個線程對應的代碼：
??線程的執行中，先用 synchronized 獲得了這個對象的 Monitor（對應于 locked <0xef63beb8> ）。當執行到 obj.wait(), 線程即放棄了 Monitor的所有權，進入 “wait set”隊列（對應于 waiting on <0xef63beb8> ）。
??往往在你的程序中，會出現多個類似的線程，他們都有相似的 DUMP信息。這也可能是正常的。比如，在程序中，有多個服務線程，設計成從一個隊列里面讀取請求數據。這個隊列就是 lock以及 waiting on的對象。當隊列為空的時候，這些線程都會在這個隊列上等待，直到隊列有了數據，這些線程被 Notify，當然只有一個線程獲得了 lock，繼續執行，而其它線程繼續等待。
七. JDK 5.0 的 lock
??上面我們提到如果 synchronized和 monitor機制運用不當，可能會造成多線程程序的性能問題。在 JDK 5.0中，引入了 Lock機制，從而使開發者能更靈活的開發高性能的并發多線程程序，可以替代以往 JDK中的 synchronized和 Monitor的 機制。但是，要注意的是，因為 Lock類只是一個普通類， JVM無從得知 Lock對象的占用情況，所以在線程 DUMP中，也不會包含關于 Lock的信息， 關于死鎖等問題，就不如用 synchronized的編程方式容易識別。
八、使用實例
1、jstack pid
#jstack -l 4089 >1.txt，查看1.txt內容如下所示：
2014-03-14 10:47:04 Full thread dump Java HotSpot(TM) Client VM (20.45-b01 mixed mode, sharing):"Attach Listener" daemon prio=10 tid=0x08251400 nid=0x11bd runnable [0x00000000] java.lang.Thread.State: RUNNABLELocked ownable synchronizers: - None"DestroyJavaVM" prio=10 tid=0xb3a0a800 nid=0xffa waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLELocked ownable synchronizers: - None"Query Listener" prio=10 tid=0xb3a09800 nid=0x1023 runnable [0xb3b72000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) - locked <0x70a84430> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:462) at java.net.ServerSocket.accept(ServerSocket.java:430) at com.sun.tools.hat.internal.server.QueryListener.waitForRequests(QueryListener.java:76) at com.sun.tools.hat.internal.server.QueryListener.run(QueryListener.java:65) at java.lang.Thread.run(Thread.java:662) Locked ownable synchronizers: - None"Low Memory Detector" daemon prio=10 tid=0x08220400 nid=0x1000 runnable [0x00000000] java.lang.Thread.State: RUNNABLELocked ownable synchronizers: - None"C1 CompilerThread0" daemon prio=10 tid=0x08214c00 nid=0xfff waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLELocked ownable synchronizers: - None"Signal Dispatcher" daemon prio=10 tid=0x08213000 nid=0xffe runnable [0x00000000] java.lang.Thread.State: RUNNABLELocked ownable synchronizers: - None"Finalizer" daemon prio=10 tid=0x0820bc00 nid=0xffd in Object.wait() [0xb5075000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7a2b6f50> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0x7a2b6f50> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171)Locked ownable synchronizers: - None"Reference Handler" daemon prio=10 tid=0x0820a400 nid=0xffc in Object.wait() [0xb50c7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7a2b6fe0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x7a2b6fe0> (a java.lang.ref.Reference$Lock)Locked ownable synchronizers: - None"VM Thread" prio=10 tid=0x08200000 nid=0xffb runnable"VM Periodic Task Thread" prio=10 tid=0x08222400 nid=0x1001 waiting on conditionJNI global references: 1317??一般情況下，通過jstack輸出的線程信息主要包括：jvm自身線程、用戶線程等。其中jvm線程會在jvm啟動時就會存在。對于用戶線程則是在用戶訪問時才會生成。
2、jstack 查看線程具體在做什么，可看出哪些線程在長時間占用CPU，盡快定位問題和解決問題:JVM性能調優——使用jstack找出最耗CPU的java線程
九、遇到線程問題時如何分析
1、線程Dump的分析原則
??結合代碼閱讀的推理。需要線程Dump和源碼的相互推導和印證。造成Bug的根源往往丌會在調用棧上直接體現,一定格外注意線程當前調用之前的所有調用。
入手點
進入區等待
線程狀態BLOCKED,線程動作wait on monitor entry,調用修飾waiting to lock總是一起出現。表示在代碼級別已經存在沖突的調用。必然有問題的代碼,需要盡可能減少其發生。
同步塊阻塞
一個線程鎖住某對象,大量其他線程在該對象上等待。
持續運行的IO IO操作是可以以RUNNABLE狀態達成阻塞。例如:數據庫死鎖、網絡讀寫。 格外注意對IO線程的真實狀態的分析。 一般來說,被捕捉到RUNNABLE的IO調用,都是有問題的。
??以下堆棧顯示： 線程狀態為RUNNABLE。 調用棧在SocketInputStream或SocketImpl上,socketRead0等方法。 調用棧包含了jdbc相關的包。很可能發生了數據庫死鎖
分線程調度的休眠
正常的線程池等待
可疑的線程等待
入手點總結
wait on monitor entry： 被阻塞的,肯定有問題
runnable ： 注意IO線程
in Object.wait()： 注意非線程池等待
2、死鎖分析
??學會了怎么使用jstack命令之后，我們就可以看看，如何使用jstack分析死鎖了，這也是我們一定要掌握的內容。 啥叫死鎖？ 所謂死鎖： 是指兩個或兩個以上的進程在執行過程中，由于競爭資源或者由于彼此通信而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處于死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。 說白了，我現在想吃雞蛋灌餅，桌子上放著雞蛋和餅，但是我和我的朋友同時分別拿起了雞蛋和病，我手里拿著雞蛋，但是我需要他手里的餅。他手里拿著餅，但是他想要我手里的雞蛋。就這樣，如果不能同時拿到雞蛋和餅，那我們就不能繼續做后面的工作（做雞蛋灌餅）。所以，這就造成了死鎖。 看一段死鎖的程序：
當我啟動該程序時，我們看一下控制臺：
??我們發現，程序只輸出了兩行內容，然后程序就不再打印其它的東西了，但是程序并沒有停止。這樣就產生了死鎖。 當線程1使用synchronized鎖住了o1的同時，線程2也是用synchronized鎖住了o2。當兩個線程都執行完第一個打印任務的時候，線程1想鎖住o2，線程2想鎖住o1。但是，線程1當前鎖著o1，線程2鎖著o2。所以兩個想成都無法繼續執行下去，就造成了死鎖。
??然后，我們使用jstack來看一下線程堆棧信息：
??Found 1 deadlock.堆棧寫的很明顯，它告訴我們 Found one Java-level deadlock，然后指出造成死鎖的兩個線程的內容。然后，又通過 Java stack information for the threads listed above來顯示更詳細的死鎖的信息。 他說
Thread-1在想要執行第40行的時候，當前鎖住了資源<0x00000007d6aa2ca8>,但是他在等待資源<0x00000007d6aa2c98>Thread-0在想要執行第27行的時候，當前鎖住了資源<0x00000007d6aa2c98>,但是他在等待資源<0x00000007d6aa2ca8> 由于這兩個線程都持有資源，并且都需要對方的資源，所以造成了死鎖。 原因我們找到了，就可以具體問題具體分析，解決這個死鎖了。
3、熱鎖分析
??熱鎖，也往往是導致系統性能瓶頸的主要因素。其表現特征為，由于多個線程對臨界區，或者鎖的競爭，可能出現：
* 頻繁的線程的上下文切換：從操作系統對線程的調度來看，當 線程在等待資源而阻塞的時候，操作系統會將之切換出來，放到等待的隊列，當線程獲得資源之后，調度算法會將這個線程切換進去，放到執行隊列中。
* 大量的系統調用：因為線程的上下文切換，以及熱鎖的競爭，或 者臨界區的頻繁的進出，都可能導致大量的系統調用。
* 大部分 CPU開銷用在 “系統態 ”：線程上下文切換，和系統調用，都會導致 CPU在 “系統態 ”運行，換而言之，雖然系統很忙碌，但是 CPU用在 “用戶態 ”的比例較小，應用程序得不到充分的 CPU資源。
* 隨著 CPU數目的增多，系統的性能反而下降。因為 CPU數目多，同 時運行的線程就越多，可能就會造成更頻繁的線程上下文切換和系統態的 CPU開銷，從而導致更糟糕的性能。
??上面的描述，都是一個 scalability（可擴展性）很差的系統的表現。從整體的性能指標看，由于線程熱鎖的存在，程序的響應時間會變長，吞吐量會降低。
??那么，怎么去了解 “熱鎖 ”出現在什么地方呢？一個重要的方法還是結合操作系統的各種工具觀察系統資源使用狀況，以及收集 Java線程的 DUMP信息，看線程都阻塞在什么方法上，了解原因，才能找到對應的解決方法。
? ?我們曾經遇到過這樣的例子，程序運行時，出現了以上指出的各種現象，通過觀察操作系統的資源使用統計信息，以及線程 DUMP信息，確定了程序中熱鎖的存在，并發現大多數的線程狀態都是 Waiting for monitor entry或者 Wait on monitor，且是阻塞在壓縮和解壓縮的方法上。后來采用第三方的壓縮包 javalib替代 JDK自帶的壓縮包后，系統的性能提高了幾倍。
其他
??虛擬機執行Full GC時,會阻塞所有的用戶線程。因此,即時獲取到同步鎖的線程也有可能被阻塞。 在查看線程Dump時,首先查看內存使用情況。
jstack -m 會打印出JVM堆棧信息，涉及C、C++部分代碼，可能需要配合gdb命令來分析。
頻繁GC問題或內存溢出問題
一、使用jps查看線程ID
二、使用jstat -gc 3331 250 20 查看gc情況，一般比較關注PERM區的情況，查看GC的增長情況。
三、使用jstat -gccause：額外輸出上次GC原因
四、使用jmap -dump:format=b,file=heapDump 3331生成堆轉儲文件
五、使用jhat或者可視化工具（Eclipse Memory Analyzer 、IBM HeapAnalyzer）分析堆情況。
六、結合代碼解決內存溢出或泄露問題。
死鎖問題
一、使用jps查看線程ID
二、使用jstack 3331：查看線程情況
總結
以上是生活随笔為你收集整理的【JVM性能调优】jstack和线程dump分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Redis学习】Redis开启多个端口
- 下一篇： 使用GitHub构建个人博客网站