java命令--jstack 工具查看JVM堆棧信息

阿新 • • 發佈：2019-01-28

性能問題直接 oot 總結線程鎖分享 linked rom move

一、介紹

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

常用參數說明

1）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服務

2）基本參數：

-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版在線分析工具，可以將鎖或條件相關聯的線程聚合到一起。

三、使用實例

1、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啟動時就會存在。對於用戶線程則是在用戶訪問時才會生成。

2、jstack 查看線程具體在做什麽，可看出哪些線程在長時間占用CPU，盡快定位問題和解決問題

http://www.iteye.com/topic/1114219

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，可看到當前線程在做什麽。

3、代碼示例

運行代碼：

/**
 * @author hollis
 */
public class JStackDemo1 {
    public static void main(String[] args) {
        while (true) {
            //Do Nothing
        }
    }
}

先是有jps查看進程號：

hollis@hos:~$ jps
29788 JStackDemo1
29834 Jps
22385 org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar

然後使用jstack 查看堆棧信息：

hollis@hos:~$ jstack 29788
2015-04-17 23:47:31
...此處省略若幹內容...
"main" prio=10 tid=0x00007f197800a000 nid=0x7462 runnable [0x00007f197f7e1000]
   java.lang.Thread.State: RUNNABLE
    at javaCommand.JStackDemo1.main(JStackDemo1.java:7)

我們可以從這段堆棧信息中看出什麽來呢？我們可以看到，當前一共有一條用戶級別線程,線程處於runnable狀態，執行到JStackDemo1.java的第七行。看下面代碼：

/**
 * @author hollis
 */
public class JStackDemo1 {
    public static void main(String[] args) {
        Thread thread = new Thread(new Thread1());
        thread.start();
    }
}
class Thread1 implements Runnable{
    @Override
    public void run() {
        while(true){
            System.out.println(1);
        }
    }
}

線程堆棧信息如下：

"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> ）。

四、如何分析

1、線程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()：註意非線程池等待

2、死鎖分析

學會了怎麽使用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：查看線程情況

主要參考資料：

Java命令學習系列（二）——Jstack

java jstack dump 線程介紹解釋

java命令--jstack 工具查看JVM堆棧信息

性能問題直接 oot 總結線程鎖分享 linked rom move 一、介紹 jstack是java虛擬機自帶的一種堆棧跟蹤工具。jstack用於打印出給定的java進程ID或core file或遠程調試服務的Java堆棧信息，如果是在64位機器上，需要指定選項"-

java命令--jstack 工具查看JVM堆棧信息

一、介紹

線程狀態

Monitor

調用修飾

線程動作

二、命令格式

三、使用實例

四、如何分析

1、線程Dump的分析

原則

入手點

入手點總結

2、死鎖分析

其他

頻繁GC問題或內存溢出問題

死鎖問題

java命令--jstack 工具查看JVM堆棧信息

linux命令stat，查看文件詳細信息

利用jmap和MAT等工具查看JVM運行時堆內存

Linux 下查看某個進程運行的堆棧信息

（FortiGate）飛塔防火墻查看設備基本信息命令

Java內存泄漏分析系列之一：使用jstack定位線程堆棧信息

查找現網環境中最耗費CPU的Java線程，並定位堆棧信息

在dos環境下查看python安裝包信息的命令

kill -3 pid命令獲取java應用堆棧信息

【LInux】查看Linux系統版本信息

[administrative][archlinux][netctl][wpa_supplicant] 查看WIFI鏈接信息

如何查看oracle當前session信息

FFmpeg查看媒體文件信息

給虛擬機添加新硬盤並分區，fdisk查看分區，分區，重新讀取分區表信息partprobe，格式化，掛載，查看分區掛載信息

Chrome 瀏覽器中查看 webSocket 連接信息

查看Linux系統版本信息

利用CMD查看系統硬件信息

sqlserver_query2_查看數據庫信息|查看服務器名稱|查看實例名

Linux系統查看服務器相關信息

ESXi主機查看硬盤健康信息（SMART）

java命令--jstack 工具 查看JVM堆棧信息

一、介紹

線程狀態

Monitor

調用修飾

線程動作

二、命令格式

三、使用實例

四、如何分析

1、線程Dump的分析

原則

入手點

入手點總結

2、死鎖分析

其他

頻繁GC問題或內存溢出問題

死鎖問題

相關推薦

java命令--jstack 工具查看JVM堆棧信息