1.總述
jstack是jvm虛擬機(jī)自帶的一種堆棧分析工具，用于打印出給定的java進(jìn)程或者core file或者遠(yuǎn)程調(diào)試服務(wù)的堆棧信息等。主要分為兩個功能如下：
a.針對活著的進(jìn)程做本地的或者遠(yuǎn)程的線程的dump
b.針對core文件做線程dump
jstack命令可以快捷的定位線程出現(xiàn)長時間停頓的原因，如線程間死鎖，死循環(huán)，請求外部的資源導(dǎo)致長時間的等待等。
jstack的基本用法
我們在控制臺輸入 jstack -help，打印如下信息：
[root@izvwwt3webhi84z ~]# jstack -help
Usage:
jstack [-l] <pid>
(to connect to running process)
jstack -F [-m] [-l] <pid>
(to connect to a hung process)
jstack [-m] [-l] <executable> <core>
(to connect to a core file)
jstack [-m] [-l] [server_id@]<remote server IP or hostname>
(to connect to a remote debug server)
Options:
-F to force a thread dump. Use when jstack <pid> does not respond (process is hung)
-m to print both java and native frames (mixed mode)
-l long listing. Prints additional information about locks
-h or -help to print this help message
可以看到有3個參數(shù)可供我們的各種需求。
-F 執(zhí)行線程轉(zhuǎn)儲
-m 打印java和本地幀
-l打印列表信息，包括鎖相關(guān)的信息
線程狀態(tài)
想要通過jstack查看線程的情況的話，有必要了解線程的幾種執(zhí)行狀態(tài)，下面這些狀態(tài)是我們通過jstack查看線程堆棧信息時可能會看到的：
RUNNABLE,在虛擬機(jī)內(nèi)執(zhí)行的。運(yùn)行中狀態(tài)，可能里面還能看到locked字樣，表明它獲得了某把鎖。
BLOCKED,受阻塞并等待監(jiān)視器鎖。被某個鎖(synchronizers)給block住了。
WATING,無限期等待另一個線程執(zhí)行特定操作。等待某個condition或monitor發(fā)生，一般停留在park(), wait(), sleep(),join() 等語句里。
TIMED_WATING,有時限的等待另一個線程的特定操作。和WAITING的區(qū)別是wait() 等語句加上了時間限制 wait(timeout)。
TERMINATED,已退出的
調(diào)用修飾
表示線程在調(diào)用的時候的額外的重要的操作，線程dump分析的重要信息
locked <地址> 使用synchronized申請對象鎖成功后，監(jiān)視器的擁有者
waiting to lock <地址>使用synchronized申請鎖對象失敗，在進(jìn)入?yún)^(qū)等待
waiting on <地址>使用synchronized申請鎖對象成功后，在等待區(qū)等待
parking to wait for <地址>調(diào)用了park方法
線程動作
in object wait() <地址>等待區(qū)等待，線程狀態(tài)可為waiting或者timed_waiting
Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f86a4102000 nid=0xac7 in Object.wait() [0x00007f868edf4000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000000ea2e6d10> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
runnable運(yùn)行狀態(tài)
waiting on condition <地址>線程狀態(tài)可為runnable，waiting(parking)或者timed_waiting (sleeping)
logback-1" #10 daemon prio=5 os_prio=0 tid=0x00007f86a42db000 nid=0xacf waiting on condition [0x00007f868c3e1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000ea203980> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
C1 CompilerThread1 daemon prio=9 os_prio=0 tid=0x00007f86a413e000 nid=0xacb waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
使用實例
jstack查看線程具體在做什么，查看哪些線程在長時間占用cpu，盡快發(fā)現(xiàn)問題和解決問題
a.用top命令查看進(jìn)程消耗cpu的情況，查看消耗高的進(jìn)程來分析。
top - 23:03:18 up 48 days, 2:07, 2 users, load average: 0.00, 0.01, 0.05
Tasks: 99 total, 1 running, 98 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.8 us, 0.7 sy, 0.0 ni, 98.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8010460 total, 459580 free, 5867196 used, 1683684 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1809732 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18602 root 20 0 2808772 281956 13840 S 0.7 3.5 6:22.06 java
27484 root 20 0 2947772 417468 14152 S 0.7 5.2 2:52.65 java
32473 root 20 0 2872624 332384 13944 S 0.7 4.1 37:09.33 java
1243 mysql 20 0 1621728 363796 5944 S 0.3 4.5 29:41.37 mysqld
1512 root 20 0 3644460 366936 13808 S 0.3 4.6 21:18.60 java
b.我們可以看到18602的進(jìn)程消耗cpu比價高，于是可以分析該進(jìn)程下的線程的使用情況。在控制臺輸入 top -Hp 18602，如下所示
18603 root 15 0 1807m 630m 9492 S 1.3 4.0 0:05.12 java
20503 root 15 0 1360m 560m 9176 S 0.3 3.6 0:46.72 java
我們來分析18603線程，并且注意18603的線程是屬于18602進(jìn)程的。
輸入jstack 18602 | grep -A 10 [線程的16進(jìn)制]即jstack 18602 | grep -A 10 48ab,得到如下結(jié)果
[root@izvwwt3webhi84z ~]# jstack 18602 | grep -A 10 48ab
"DestroyJavaVM" #28 prio=5 os_prio=0 tid=0x00007f119cb24000 nid=0x48ab waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"New I/O server boss #4" #24 daemon prio=5 os_prio=0 tid=0x00007f119d1c6000 nid=0x48c4 runnable [0x00007f1158912000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x00000000f28b7538> (a sun.nio.ch.Util$3)
- locked <0x00000000f28b7548> (a java.util.Collections$UnmodifiableSet)
于是我們可以根據(jù)堆棧信息來分析問題了。
這里附上進(jìn)制轉(zhuǎn)換的網(wǎng)站https://www.sojson.com/hexconvert.html
