Java線程棧的獲取和分析

獲取進程號

使用命令：jps

經常使用參數：

 -m 輸出傳遞給main方法的參數，若是是內嵌的JVM則輸出爲null。

 -l 輸出應用程序主類的完整包名，或者是應用程序JAR文件的完整路徑。

 -v 輸出傳給JVM的參數。

示例：

線程棧的獲取

使用命令：jstack，一般使用管道將信息輸出到文件，便於分析

經常使用參數：

 -F 當jstack沒有響應的時候強制打印棧信息。

 -l 打印關於鎖的附加信息，例如屬於java.util.concurrent的ownable synchronizers列表。

 -m 打印java和native c/c++框架的全部棧信息。

示例：

線程棧內容示例

2016-03-07 18:04:57
Full thread dump Java HotSpot(TM) Client VM (24.80-b11 mixed mode):

"Attach Listener" daemon prio=10 tid=0xb7675000 nid=0x4a9 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Service Thread" daemon prio=10 tid=0xb766ec00 nid=0x44a runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"C1 CompilerThread0" daemon prio=10 tid=0xb766d000 nid=0x449 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Signal Dispatcher" daemon prio=10 tid=0xb766b400 nid=0x448 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Finalizer" daemon prio=10 tid=0xb765ac00 nid=0x447 in Object.wait() [0xa14ad000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa1a04750> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0xa1a04750> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

   Locked ownable synchronizers:
	- None

"Reference Handler" daemon prio=10 tid=0xb7659400 nid=0x446 in Object.wait() [0xa14fe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa1a043b8> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:503)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
	- locked <0xa1a043b8> (a java.lang.ref.Reference$Lock)

   Locked ownable synchronizers:
	- None

"main" prio=10 tid=0xb7606400 nid=0x444 waiting on condition [0xb77f2000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at Test.main(Test.java:5)

   Locked ownable synchronizers:
	- None

"VM Thread" prio=10 tid=0xb7656800 nid=0x445 runnable 

"VM Periodic Task Thread" prio=10 tid=0xb7671400 nid=0x44b waiting on condition 

JNI global references: 125

線程棧各部分介紹

　　頭部信息：

　　示例：

　　2016-03-07 18:04:57

　　Full thread dump Java HotSpot(TM) Client VM (24.80-b11 mixed mode):

　　內容：

　　時間，jvm信息

　　

　　線程info信息塊：

　　示例：

　　"Finalizer" daemon prio=10 tid=0xb765ac00 nid=0x447 in Object.wait() [0xa14ad000]

　　   java.lang.Thread.State: WAITING (on object monitor)

　　at java.lang.Object.wait(Native Method)

　　- waiting on <0xa1a04750> (a java.lang.ref.ReferenceQueue$Lock)

　　at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)

　　- locked <0xa1a04750> (a java.lang.ref.ReferenceQueue$Lock)

　　at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)

　　at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

　　

　　   Locked ownable synchronizers:

　　- None

　　內容：    

　　線程名稱：如Finalizer

　　線程類型：如daemon

　　優先級: 10，默認是5，如prio=10

　　jvm線程id：tid=0xb765ac00，jvm內部線程的惟一標識（經過java.lang.Thread.getId()獲取，一般用自增方式實現。）

　　對應系統線程id（Native Thread ID）：nid=0x447，和top命令查看的線程pid對應，不過一個是10進制，一個是16進制。（經過命令：top -H -p pid，能夠查看該進程的全部線程信息）

　　線程狀態：in Object.wait().

　　起始棧地址：[0xa14ad000]

　　線程棧部分：包括線程當前狀態和線程棧

線程棧分析工具

　　IBM Thread and Monitor Dump Analyzer for Java

　　官網主頁：https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=2245aa39-fa5c-4475-b891-14c205f7333c&lang=zh

　　該工具是一個Jar包，可使用命令啓動

java -jar jca457.jar

　　工做界面以下

JVM中的線程狀態

　　線程在JVM中的各個狀態

　　1.死鎖，Deadlock（重點關注） 

　　2.執行中，Runnable（重點關注）   

　　3.等待資源，Waiting on condition（重點關注）

　　4.等待監控器檢查資源，Waiting on monitor(eg:若是使用System.out.println等須要分配計算機資源的時候線程會如此等待,主要還需看堆棧)

　　5.暫停，Suspended

　　6.對象等待中，Object.wait()

　　7.阻塞，Blocked（重點關注）  

　　8.中止，Parked(主要是指線程空閒時候的狀態。如在線程池中，當線程被調用後再次放入到池子中，則其狀態變爲了Parked)

JVM的Thin Lock, Fat Lock, Spin Lock與Tasuki Lock

　　Java不少ThreadDump中，均可以看到Thin Lock, Fat Lock, Spin Lock，這些Lock都與Java語言、OS有密切的關係。

　　回到一個簡單的問題，在Java中，如何實現Synchronizd？

　　最簡單的一種作法是，利用OS的mutex機制，把Java的同步（基於Object），翻譯成OS相關的monitor_enter和monitor_exit原語。

　　回到Java鎖自己，鎖在不一樣的應用下有着不一樣的統計表現，而大部分的統計數據代表，其實線程搶鎖，即鎖競爭，都是短暫的，在大部分的狀況下，幾乎都不會發生鎖競爭的現象。

　　也就是說，Java鎖，從安全性的角度來看，是有點累贅。

　　所以，大量的專家都在鎖上針對這樣的統計特性對Java鎖進行優化。

　　其中一種優化方案是，咱們對全部的鎖都須要monitor_enter和monitor_exit嗎？事實上不須要。

　　若是咱們把monitor_enter/monitor_exit當作是Fat Lock方式，則能夠把Thin Lock當作是一種基於CAS（Compare and Swap）的簡易實現。

　　這兩種鎖，簡單一點理解，就是：

　　而基於CAS方式的實現，線程進入競爭狀態的，得到鎖的線程，會讓其餘線程處於自旋狀態（也稱之爲Spin Mode，即自旋），這是一種while(Lock_release) doStuff()的Busy-Wait方式，是一種耗CPU的方式；而Fat Lock方式下，一個線程得到鎖的時候，其餘線程能夠先sleep，等鎖釋放後，再喚醒（Notify）。

　　CAS的優勢是快，若是沒有線程競爭的狀況下，由於CAS只須要一個指令便得到鎖，因此稱之爲Thin Lock，缺點也是很明顯的，即若是頻繁發生線程競爭，CAS是低效，主要表現爲，排斥在鎖以外的線程是Busy Wait狀態；而monitor_enter/monitor_exit/monitor_notify方式，則是重量級的，在線程產生競爭的時候，Fat Lock在OS mutex方式下，能夠實現no busy-wait。

　　因而，JVM早期版本的作法是，若是T1, T2，T3，T4...產生線程競爭，則T1經過CAS得到鎖(此時是Thin Lock方式)，若是T1在CAS期間得到鎖，則T2，T3進入SPIN狀態直到T1釋放鎖；而第二個得到鎖的線程，好比T2，會將鎖升級（Inflation）爲Fat Lock，因而，之後嘗試得到鎖的線程都使用Mutex方式得到鎖。

　　這種設計爲鎖提供了兩條路徑：Thin Lock路徑和Fat Lock路徑，大部分狀況下，可能都是走Thin Lock路徑，而可能少部分狀況，是走Fat Lock路徑，這種方式提供了鎖升級，可是避免不了Busy Wait，並且Thin-Lock升級Fat-Lock以後，沒有辦法回退到Thin-Lock（性能比Fat-Lock更好）。

　　Tasuki鎖爲這種方式作了2個優化：

　　1) 避免CAS致使Busy wait

　　2) Fat Lock能夠deflate(與Inflate恰好相反)爲Thin Lock(以前是Thin Lock變成Fat Lock以後便不能再回退)。

　　通過這樣的改造後，鎖性能提升了10%以上。

　　目前，Oracle的BEA JRockit與IBM的JVM都實現了Tasuki鎖機制，惟一的不一樣是，在鎖實現上都作了不一樣啓發式的設計，即根據運行時採樣的數據，動態調整一些權值數據，一邊左右Lock Inflation/Lock Defaltion的過程（一顆樹的兩個分支），獲取更好的鎖性能。

參考文獻

　　Java線程池中線程的狀態簡介

　　性能分析之-- JAVA Thread Dump 分析綜述

　　關於JVM的Thin Lock, Fat Lock, SPIN Lock與Tasuki Lock