1.总述
jstack是jvm虚拟机自带的一种堆栈分析工具，用于打印出给定的java进程或者core file或者远程调试服务的堆栈信息等。主要分为两个功能如下：
a.针对活着的进程做本地的或者远程的线程的dump
b.针对core文件做线程dump
jstack命令可以快捷的定位线程出现长时间停顿的原因，如线程间死锁，死循环，请求外部的资源导致长时间的等待等。
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个参数可供我们的各种需求。
-F 执行线程转储
-m 打印java和本地帧
-l打印列表信息，包括锁相关的信息
线程状态
想要通过jstack查看线程的情况的话，有必要了解线程的几种执行状态，下面这些状态是我们通过jstack查看线程堆栈信息时可能会看到的：
RUNNABLE,在虚拟机内执行的。运行中状态，可能里面还能看到locked字样，表明它获得了某把锁。
BLOCKED,受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。
WATING,无限期等待另一个线程执行特定操作。等待某个condition或monitor发生，一般停留在park(), wait(), sleep(),join() 等语句里。
TIMED_WATING,有时限的等待另一个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。
TERMINATED,已退出的
调用修饰
表示线程在调用的时候的额外的重要的操作，线程dump分析的重要信息
locked <地址> 使用synchronized申请对象锁成功后，监视器的拥有者
waiting to lock <地址>使用synchronized申请锁对象失败，在进入区等待
waiting on <地址>使用synchronized申请锁对象成功后，在等待区等待
parking to wait for <地址>调用了park方法
线程动作
in object wait() <地址>等待区等待，线程状态可为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运行状态
waiting on condition <地址>线程状态可为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，尽快发现问题和解决问题
a.用top命令查看进程消耗cpu的情况，查看消耗高的进程来分析。
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的进程消耗cpu比价高，于是可以分析该进程下的线程的使用情况。在控制台输入 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进程的。
输入jstack 18602 | grep -A 10 [线程的16进制]即jstack 18602 | grep -A 10 48ab,得到如下结果
[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)
于是我们可以根据堆栈信息来分析问题了。
这里附上进制转换的网站https://www.sojson.com/hexconvert.html
