介紹
jstack是java虛擬機自帶的一種堆棧跟蹤工具。jstack用於打印出給定的java進程ID或core file或遠程調試服務的Java堆棧信息，如果是在64位機器上，需要指定選項"-J-d64"，Windows的jstack使用方式只支持以下的這種方式：
jstack [-l] pid
主要分為兩個功能：
a． 針對活着的進程做本地的或遠程的線程dump；
b． 針對core文件做線程dump。
jstack用於生成java虛擬機當前時刻的線程快照。線程快照是當前java虛擬機內每一條線程正在執行的方法堆棧的集合，生成線程快照的主要目的是定位線程出現長時間停頓的原因，如線程間死鎖、死循環、請求外部資源導致的長時間等待等。 線程出現停頓的時候通過jstack來查看各個線程的調用堆棧，就可以知道沒有響應的線程到底在后台做什么事情，或者等待什么資源。 如果java程序崩潰生成core文件，jstack工具可以用來獲得core文件的java stack和native stack的信息，從而可以輕松地知道java程序是如何崩潰和在程序何處發生問題。另外，jstack工具還可以附屬到正在運行的java程序中，看到當時運行的java程序的java stack和native stack的信息, 如果現在運行的java程序呈現hung的狀態，jstack是非常有用的。
So,jstack命令主要用來查看Java線程的調用堆棧的，可以用來分析線程問題（如死鎖）。
線程狀態
想要通過jstack命令來分析線程的情況的話，首先要知道線程都有哪些狀態，下面這些狀態是我們使用jstack命令查看線程堆棧信息時可能會看到的線程的幾種狀態：
NEW,未啟動的。不會出現在Dump中。
RUNNABLE,在虛擬機內執行的。運行中狀態，可能里面還能看到locked字樣，表明它獲得了某把鎖。
BLOCKED,受阻塞並等待監視器鎖。被某個鎖(synchronizers)給block住了。
WATING,無限期等待另一個線程執行特定操作。等待某個condition或monitor發生，一般停留在park(), wait(), sleep(),join() 等語句里。
TIMED_WATING,有時限的等待另一個線程的特定操作。和WAITING的區別是wait() 等語句加上了時間限制 wait(timeout)。
TERMINATED,已退出的。
Monitor
在多線程的 JAVA程序中，實現線程之間的同步，就要說說 Monitor。 Monitor是 Java中用以實現線程之間的互斥與協作的主要手段，它可以看成是對象或者 Class的鎖。每一個對象都有，也僅有一個 monitor。下 面這個圖，描述了線程和 Monitor之間關系，以 及線程的狀態轉換圖：
進入區(Entrt Set):表示線程通過synchronized要求獲取對象的鎖。如果對象未被鎖住,則迚入擁有者;否則則在進入區等待。一旦對象鎖被其他線程釋放,立即參與競爭。
擁有者(The Owner):表示某一線程成功競爭到對象鎖。
等待區(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分析的重要信息。修飾上方的方法調用。
locked <地址> 目標：使用synchronized申請對象鎖成功,監視器的擁有者。
waiting to lock <地址> 目標：使用synchronized申請對象鎖未成功,在迚入區等待。
waiting on <地址> 目標：使用synchronized申請對象鎖成功后,釋放鎖幵在等待區等待。
parking to wait for <地址> 目標
- locked
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at com.jiuqi.dna.core.internal.db.datasource.PooledConnection.prepareStatement
通過synchronized關鍵字,成功獲取到了對象的鎖,成為監視器的擁有者,在臨界區內操作。對象鎖是可以線程重入的。
- waiting to lock
at com.jiuqi.dna.core.impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
- waiting to lock <0x0000000097ba9aa8> (a CacheHolder)
at com.jiuqi.dna.core.impl.CacheGroup$Index.findHolder
at com.jiuqi.dna.core.impl.ContextImpl.find
at com.jiuqi.dna.bap.basedata.common.util.BaseDataCenter.findInfo
通過synchronized關鍵字,沒有獲取到了對象的鎖,線程在監視器的進入區等待。在調用棧頂出現,線程狀態為Blocked。
- waiting on
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000da2defb0> (a WorkingThread)
at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo
- locked <0x00000000da2defb0> (a WorkingThread)
at com.jiuqi.dna.core.impl.WorkingThread.run
通過synchronized關鍵字,成功獲取到了對象的鎖后,調用了wait方法,進入對象的等待區等待。在調用棧頂出現,線程狀態為WAITING或TIMED_WATING。
- parking to wait for
park是基本的線程阻塞原語,不通過監視器在對象上阻塞。隨concurrent包會出現的新的機制,不synchronized體系不同。
線程動作
線程狀態產生的原因:
runnable:狀態一般為RUNNABLE。
in Object.wait():等待區等待,狀態為WAITING或TIMED_WAITING。
waiting for monitor entry:進入區等待,狀態為BLOCKED。
waiting on condition:等待區等待、被park。
sleeping:休眠的線程,調用了Thread.sleep()。
Wait on condition 該狀態出現在線程等待某個條件的發生。具體是什么原因，可以結合 stacktrace來分析。 最常見的情況就是線程處於sleep狀態，等待被喚醒。 常見的情況還有等待網絡IO：在java引入nio之前，對於每個網絡連接，都有一個對應的線程來處理網絡的讀寫操作，即使沒有可讀寫的數據，線程仍然阻塞在讀寫操作上，這樣有可能造成資源浪費，而且給操作系統的線程調度也帶來壓力。在 NewIO里采用了新的機制，編寫的服務器程序的性能和可擴展性都得到提高。 正等待網絡讀寫，這可能是一個網絡瓶頸的征兆。因為網絡阻塞導致線程無法執行。一種情況是網絡非常忙，幾 乎消耗了所有的帶寬，仍然有大量數據等待網絡讀 寫；另一種情況也可能是網絡空閑，但由於路由等問題，導致包無法正常的到達。所以要結合系統的一些性能觀察工具來綜合分析，比如 netstat統計單位時間的發送包的數目，如果很明顯超過了所在網絡帶寬的限制 ; 觀察 cpu的利用率，如果系統態的 CPU時間，相對於用戶態的 CPU時間比例較高；如果程序運行在 Solaris 10平台上，可以用 dtrace工具看系統調用的情況，如果觀察到 read/write的系統調用的次數或者運行時間遙遙領先；這些都指向由於網絡帶寬所限導致的網絡瓶頸。（來自http://www.blogjava.net/jzone/articles/303979.html）
命令格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP
常用參數說明
- options：
executable Java executable from which the core dump was produced.(可能是產生core dump的java可執行程序)
core 將被打印信息的core dump文件
remote-hostname-or-IP 遠程debug服務的主機名或ip
server-id 唯一id,假如一台主機上多個遠程debug服務
- 基本參數
-F 當’jstack [-l] pid’沒有相應的時候強制打印棧信息,如果直接jstack無響應時，用於強制jstack），一般情況不需要使用
-l 長列表. 打印關於鎖的附加信息,例如屬於java.util.concurrent的ownable synchronizers列表，會使得JVM停頓得長久得多（可能會差很多倍，比如普通的jstack可能幾毫秒和一次GC沒區別，加了-l 就是近一秒的時間），-l 建議不要用。一般情況不需要使用
-m 打印java和native c/c++框架的所有棧信息.可以打印JVM的堆棧,顯示上Native的棧幀，一般應用排查不需要使用
-h | -help打印幫助信息
pid 需要被打印配置信息的java進程id,可以用jps查詢.
- 線程dump的分析工具：
IBM Thread and Monitor Dump Analyze for Java 一個小巧的Jar包，能方便的按狀態，線程名稱，線程停留的函數排序，快速瀏覽。
http://spotify.github.io/threaddump-analyzer Spotify提供的Web版在線分析工具，可以將鎖或條件相關聯的線程聚合到一起。
使用實例
jstack pid
~$ jps -ml
org.apache.catalina.startup.Bootstrap
~$ jstack 5661
2013-04-16 21:09:27
Full thread dump Java HotSpot(TM) Server VM (20.10-b01 mixed mode):
"Attach Listener" daemon prio=10 tid=0x70e95400 nid=0x2265 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"http-bio-8080-exec-20" daemon prio=10 tid=0x08a35800 nid=0x1d42 waiting on condition [0x70997000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x766a27b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
........
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: RUNNABLE
Locked ownable synchronizers:
- None
"DestroyJavaVM" prio=10 tid=0xb3a0a800 nid=0xffa waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked 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: RUNNABLE
Locked ownable synchronizers:
- None
"C1 CompilerThread0" daemon prio=10 tid=0x08214c00 nid=0xfff waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Signal Dispatcher" daemon prio=10 tid=0x08213000 nid=0xffe runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked 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 condition
JNI global references: 1317
一般情況下，通過jstack輸出的線程信息主要包括：jvm自身線程、用戶線程等。其中jvm線程會在jvm啟動時就會存在。對於用戶線程則是在用戶訪問時才會生成。
jstack 查看線程具體在做什么，可看出哪些線程在長時間占用CPU，盡快定位問題和解決問題
1.top查找出哪個進程消耗的cpu高。執行top命令，默認是進程視圖，其中PID是進程號
21125 co_ad2 18 0 1817m 776m 9712 S 3.3 4.9 12:03.24 java
5284 co_ad 21 0 3028m 2.5g 9432 S 1.0 16.3 6629:44 ja
這里我們分析21125這個java進程
2.top中shift+h 或“H”查找出哪個線程消耗的cpu高
先輸入top，然后再按shift+h 或“H”，此時打開的是線程視圖，pid為線程號
21233 co_ad2 15 0 1807m 630m 9492 S 1.3 4.0 0:05.12 java
20503 co_ad2_s 15 0 1360m 560m 9176 S 0.3 3.6 0:46.72 java
這里我們分析21233這個線程，並且注意的是，這個線程是屬於21125這個進程的。
3.使用jstack命令輸出這一時刻的線程棧，保存到文件，命名為jstack.log。注意：輸出線程棧和保存top命令快照盡量同時進行。 由於jstack.log文件記錄的線程ID是16進制，需要將top命令展示的線程號轉換為16進制。4. jstack查找這個線程的信息
jstack [進程]|grep -A 10 [線程的16進制]
即： jstack 21125|grep -A 10 52f1
-A 10表示查找到所在行的后10行。21233用計算器轉換為16進制52f1，注意字母是小寫。
結果：
"http-8081-11" daemon prio=10 tid=0x00002aab049a1800 nid=0x52bb in Object.wait() [0x0000000042c75000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416)
在結果中查找52f1，可看到當前線程在做什么。
堆棧信息：
"Reference Handler" daemon prio=10 tid=0x00007fbbcc06e000 nid=0x286c in Object.wait() [0x00007fbbc8dfc000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000783e066e0> (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 <0x0000000783e066e0> (a java.lang.ref.Reference$Lock)
我們能看到：
線程的狀態： WAITING 線程的調用棧 線程的當前鎖住的資源： <0x0000000783e066e0> 線程當前等待的資源：<0x0000000783e066e0>
為什么同時鎖住的等待同一個資源：
線程的執行中，先獲得了這個對象的 Monitor（對應於 locked <0x0000000783e066e0>）。當執行到 obj.wait(), 線程即放棄了 Monitor的所有權，進入 “wait set”隊列（對應於 waiting on <0x0000000783e066e0> ）。
如何分析
dump的分析
原則
結合代碼閱讀的推理。需要線程Dump和源碼的相互推導和印證。
造成Bug的根源往往丌會在調用棧上直接體現,一定格外注意線程當前調用之前的所有調用。
入手點
- 進入區等待
"d&a-3588" daemon waiting for monitor entry [0x000000006e5d5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()
- waiting to lock <0x0000000602f38e90> (a java.lang.Object)
at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()
線程狀態BLOCKED,線程動作wait on monitor entry,調用修飾waiting to lock總是一起出現。表示在代碼級別已經存在沖突的調用。必然有問題的代碼,需要盡可能減少其發生。
- 同步塊阻塞
一個線程鎖住某對象,大量其他線程在該對象上等待。
"blocker" runnable
java.lang.Thread.State: RUNNABLE
at com.jiuqi.hcl.javadump.Blocker$1.run(Blocker.java:23)
- locked <0x00000000eb8eff68> (a java.lang.Object)
"blockee-11" waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)
- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)
"blockee-86" waiting for monitor entry
java.lang.Thread.State: BLOCKED (on object monitor)
at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)
- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)
持續運行的IO IO操作是可以以RUNNABLE狀態達成阻塞。例如:數據庫死鎖、網絡讀寫。 格外注意對IO線程的真實狀態的分析。 一般來說,被捕捉到RUNNABLE的IO調用,都是有問題的。
以下堆棧顯示： 線程狀態為RUNNABLE。 調用棧在SocketInputStream或SocketImpl上,socketRead0等方法。 調用棧包含了jdbc相關的包。很可能發生了數據庫死鎖
"d&a-614" daemon prio=6 tid=0x0000000022f1f000 nid=0x37c8 runnable
[0x0000000027cbd000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at oracle.net.ns.Packet.receive(Packet.java:240)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:172)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:117)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:588)
- 分線程調度的休眠
- 正常的線程池等待
"d&a-131" in Object.wait()
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo(WorkingManager.java:322)
- locked <0x0000000313f656f8> (a com.jiuqi.dna.core.impl.WorkingThread)
at com.jiuqi.dna.core.impl.WorkingThread.run(WorkingThread.java:40)
- 可疑的線程等待
"d&a-121" in Object.wait()
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.jiuqi.dna.core.impl.AcquirableAccessor.exclusive()
- locked <0x00000003011678d8> (a com.jiuqi.dna.core.impl.CacheGroup)
at com.jiuqi.dna.core.impl.Transaction.lock()
入手點總結
wait on monitor entry： 被阻塞的,肯定有問題
runnable ： 注意IO線程
in Object.wait()： 注意非線程池等待
死鎖分析
學會了怎么使用jstack命令之后，我們就可以看看，如何使用jstack分析死鎖了，這也是我們一定要掌握的內容。 啥叫死鎖？ 所謂死鎖： 是指兩個或兩個以上的進程在執行過程中，由於競爭資源或者由於彼此通信而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。 說白了，我現在想吃雞蛋灌餅，桌子上放着雞蛋和餅，但是我和我的朋友同時分別拿起了雞蛋和病，我手里拿着雞蛋，但是我需要他手里的餅。他手里拿着餅，但是他想要我手里的雞蛋。就這樣，如果不能同時拿到雞蛋和餅，那我們就不能繼續做后面的工作（做雞蛋灌餅）。所以，這就造成了死鎖。 看一段死鎖的程序：
package javaCommand;
/**
* @author hollis
*/
public class JStackDemo {
public static void main(String[] args) {
Thread t1 = new Thread(new DeadLockclass(true));//建立一個線程
Thread t2 = new Thread(new DeadLockclass(false));//建立另一個線程
t1.start();//啟動一個線程
t2.start();//啟動另一個線程
}
}
class DeadLockclass implements Runnable {
public boolean falg;// 控制線程
DeadLockclass(boolean falg) {
this.falg = falg;
}
public void run() {
/**
* 如果falg的值為true則調用t1線程
*/
if (falg) {
while (true) {
synchronized (Suo.o1) {
System.out.println("o1 " + Thread.currentThread().getName());
synchronized (Suo.o2) {
System.out.println("o2 " + Thread.currentThread().getName());
}
}
}
}
/**
* 如果falg的值為false則調用t2線程
*/
else {
while (true) {
synchronized (Suo.o2) {
System.out.println("o2 " + Thread.currentThread().getName());
synchronized (Suo.o1) {
System.out.println("o1 " + Thread.currentThread().getName());
}
}
}
}
}
}
class Suo {
static Object o1 = new Object();
static Object o2 = new Object();
}
當我啟動該程序時，我們看一下控制台：
我們發現，程序只輸出了兩行內容，然后程序就不再打印其它的東西了，但是程序並沒有停止。這樣就產生了死鎖。 當線程1使用synchronized鎖住了o1的同時，線程2也是用synchronized鎖住了o2。當兩個線程都執行完第一個打印任務的時候，線程1想鎖住o2，線程2想鎖住o1。但是，線程1當前鎖着o1，線程2鎖着o2。所以兩個想成都無法繼續執行下去，就造成了死鎖。
然后，我們使用jstack來看一下線程堆棧信息：
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x00007f0134003ae8 (object 0x00000007d6aa2c98, a java.lang.Object),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00007f0134006168 (object 0x00000007d6aa2ca8, a java.lang.Object),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at javaCommand.DeadLockclass.run(JStackDemo.java:40)
- waiting to lock <0x00000007d6aa2c98> (a java.lang.Object)
- locked <0x00000007d6aa2ca8> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)
"Thread-0":
at javaCommand.DeadLockclass.run(JStackDemo.java:27)
- waiting to lock <0x00000007d6aa2ca8> (a java.lang.Object)
- locked <0x00000007d6aa2c98> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)
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> 由於這兩個線程都持有資源，並且都需要對方的資源，所以造成了死鎖。 原因我們找到了，就可以具體問題具體分析，解決這個死鎖了。
其他
虛擬機執行Full GC時,會阻塞所有的用戶線程。因此,即時獲取到同步鎖的線程也有可能被阻塞。 在查看線程Dump時,首先查看內存使用情況。
對於jstack做的ThreadDump的棧，可以反映如下信息（源自）：
如果某個相同的call stack經常出現， 我們有80%的以上的理由確定這個代碼存在性能問題（讀網絡的部分除外）；
如果相同的call stack出現在同一個線程上（tid）上， 我們很很大理由相信， 這段代碼可能存在較多的循環或者死循環；
如果某call stack經常出現， 並且里面帶有lock，請檢查一下這個lock的產生的原因， 可能是全局lock造成了性能問題；
在一個不大壓力的群集里（w<2）， 我們是很少拿到帶有業務代碼的stack的， 並且一般在一個完整stack中， 最多只有1-2業務代碼的stack，
如果經常出現， 一定要檢查代碼， 是否出現性能問題。
如果你懷疑有dead lock問題， 那么請把所有的lock id找出來，看看是不是出現重復的lock id。
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：查看線程情況