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