JDK 常用工具 —— jstack 详解

jstack 是 JDK 自带的一种堆栈跟踪工具，可用于生成 JVM 当前时刻的线程快照。线程快照是当前 JVM 内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。线程出现停顿的时候通过 jstack 来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。如果 java 程序崩溃生成 core 文件，jstack 工具可以用来获得 core 文件的 java stack 和 native stack 的信息，从而可以知道 java 程序是如何崩溃和在程序何处发生问题。另外，jstack 工具还可以 attach 到正在运行的 java 程序中，看到当时运行的 java 程序的 java stack 和 native stack的信息, 如果现在运行的 java 程序呈现 hung 的状态，jstack 是非常有用的。

简而言之，jstack 主要用来查看 Java 线程的调用堆栈，可以用来分析线程问题（如死锁、死循环、CPU 占用过高）。

语法

最常见用法

jstack [options] <pid>

-F：当正常输出的请求不被响应时，强制输出线程堆栈
-m：如果调用到本地方法的话，加上此参数可以显示本地方法的堆栈
-l：最常用的一个参数，除堆栈外，显示关于锁的附加信息，在发生死锁时可以用 jstack -l pid 来观察锁持有情况

把 jstack 的输出重定向到文件中，就可以分析了。

// 比如
jstack -l <pid> >> thread.log

示例

分析死锁

线程状态

使用 jstack 查看线程堆栈信息时可能会看到的线程的几种状态：

New：创建后尚未启动的线程处于这种状态，不会出现在Dump中。
RUNNABLE：包括Running和Ready。线程开启start（）方法，会进入该状态，在虚拟机内执行的。
Waiting：无限的等待另一个线程的特定操作。
Timed Waiting：有时限的等待另一个线程的特定操作。
Blocked：在程序等待进入同步区域的时候，线程将进入这种状态，在等待监视器锁。
Terminated：已终止线程的线程状态，线程已经结束执行。

Dump 文件的线程状态一般其实就以下3种：

RUNNABLE，线程处于执行中
BLOCKED，线程被阻塞
WAITING，线程正在等待

Monitor

Monitor 是 Java 中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class 的锁。每一个对象都有，也仅有一个 monitor。下图描述了线程和 Monitor 之间的关系，以及线程的状态转换图：

进入区(Entry 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()”。

常见 dump 内容

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

waiting to lock <地址> 目标：申请对象锁未成功，在 Entry Set 等待。

// 一个线程锁住某对象，大量其他线程在该对象上等待：
"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)

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

分析流程

使用 jstack 分析死锁步骤非常简单：

jps 获取 pid
jstack -l pid 打印堆栈信息
分析堆栈信息，一般来说 Java-level 的死锁，jstack 能自动检测出来。

比如下面这段 jstack 打印的堆栈信息，就是 jstack 自动检测出了一个 Java-level 死锁：

Thread-0 锁住了<0x00000007d6aa2c98>，尝试获取 <0x00000007d6aa2ca8> 的锁
Thread-1 锁住了<0x00000007d6aa2ca8>，尝试获取 <0x00000007d6aa2c98> 的锁

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.

需要注意的是，jstack 只能自动检测 Java 线程间的死锁，不能检测到其它类型的线程状态，比如本地线程或者操作系统线程的状态。

如果要分析本地线程或者操作系统线程是否出现了死锁，可以在使用 jstack 时加上 -m 参数，把本地线程堆栈一起打印起来进行分析。

分析 CPU 占用

整体步骤：

top 查看占用 CPU 较高的进程，可以发现 pid 为 21340 的进程 CPU 占用较高。

top -Hp pid 可以查看该进程下各个线程的 CPU 使用情况，可以发现线程21350的 CPU 占用较高

jstack -l pid >> dump.log 将线程堆栈信息保存下来
分析堆栈信息，thread dump 中，每个线程对应一个十六进制的 nid（native thread id），将 21350 转成十六进制 5366 然后 grep 查看相关信息即可：

参考链接

https://www.cnblogs.com/myseries/p/12050083.html
https://juejin.cn/post/6844904152850497543
https://zhuanlan.zhihu.com/p/475571849