深入解析 JDK jstack 命令：线程分析的利器

你点赞了吗？你关注了吗？每天分享干货好文。

高并发解决方案与架构设计。

海量数据存储和性能优化。

通用框架/组件设计与封装。

如何设计合适的技术架构？

如何成功转型架构设计与技术管理？

在竞争激烈的大环境下，只有不断提升核心竞争力才能立于不败之地。

留言【我要晋级】，一对一指导，带你晋级。

引言

在 Java 应用开发中，线程问题（如死锁、CPU 占用过高、线程阻塞等）是常见的性能瓶颈和故障根源。JDK 工具 jstack 命令是分析和诊断 Java 线程状态的必备工具。

本文将从基础到实战，详细讲解 jstack 的使用方法、核心功能及常见问题的排查技巧，帮助你快速定位和解决线程相关问题。

一、jstack 是什么？

jstack 是 JDK 提供的一个命令行工具，用于生成 Java 虚拟机（JVM）的线程转储（Thread Dump）。
线程转储是 JVM 中所有线程状态的快照，包含以下关键信息：

线程的调用栈（Stack Trace）
线程的状态（RUNNABLE、BLOCKED、WAITING 等）
锁信息（持有的锁或等待的锁）
线程优先级和所属线程组

通过分析线程转储，可以快速定位死锁、线程阻塞、CPU 占用过高等问题。

二、安装与基本使用

1. 环境要求

JDK 1.6+（建议使用与目标 Java 进程相同的 JDK 版本）
jstack 位于 JDK 的 bin 目录下（如 $JAVA_HOME/bin/jstack）

2. 命令语法

jstack [options] <pid>          # 通过进程 ID 获取线程转储
jstack [options] <executable> <core>  # 分析核心转储文件
jstack [options] [server_id@]<remote server IP or hostname>  # 远程调试

常用参数：

-l：输出 详细的锁信息（如哪些线程持有锁，哪些在等待锁）
-F：强制生成线程转储（适用于进程无响应的情况）
-m：混合模式（显示 Java 和本地方法的堆栈帧）

三、实战：生成线程转储

1. 查找 Java 进程 ID

使用 jps 命令快速获取目标 Java 进程的 PID：

jps -l

2. 生成线程转储

jstack -l 12345 > thread_dump.txt  # 将输出重定向到文件

3. 强制生成转储（进程无响应时）

jstack -F -l 12345 > thread_dump_force.txt

四、线程转储分析指南

1. 线程状态解析

线程转储中的线程状态是分析问题的关键，常见状态如下：

NEW：刚创建的，还有调用 start() 之前的线程处在 NEW 状态上。此时线程与普通对象没区别，仅仅是堆中的一个线程对象而已。
RUNNABLE：正在运行，或者是具备运行条件，在运行队列中等待被 CPU 调度执行。如果线程长时间处在该状态下，说明线程运行时间长，或者一直没有CPU调度执行（线程饥饿现象）。
BLOCKED：线程在等待进入同步块或方法，本质就是在等待锁，例如被 synchronized 保护的代码块或方法。
WAITING：线程无限期等待其他线程的特定操作（如 Object.wait()）。
TIMED_WAITING：线程在有限时间内等待（如 Thread.sleep(1000)）。
TERMINATED：线程已终止，执行完 run 方法正常返回，或者抛出了运行时异常而结束，线程都会停留在这个状态。这个时候线程只剩下Thread对象了，没有什么用了。

2. 关键信息字段

"main" #1 prio=5 os_prio=0 tid=0x00007f8b4800e800 nid=0x1a03 waiting on condition [0x00007f8b50a0e000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x000000076b8a1c98> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
    at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
    at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
    at com.example.MyService.doSomething(MyService.java:42)

线程名称："main"。
线程 ID：tid=0x00007f8b4800e800。
本地线程 ID（NID）：nid=0x1a03（对应操作系统的线程 ID）。
锁信息：waiting for <0x000000076b8a1c98> 表示该线程正在等待某个锁。
prio：优先级，默认是 5

五、常见问题排查案例

常见现象：

CPU 使用率过高，响应慢

这种情况情况，需要在一次请求中进行多次 thread dump 文件的转储，做先后对比，如果 runnable 的线程前后差异大，说明系统属于正常情况，是服务器资源不够的问题，需要加大服务器资源。如果是在执行同一个方法，那就要去排查该方法的实现逻辑是否存在较大的问题，是否有优化的空间。

案例 1：死锁检测

死锁的主要表现是系统卡顿，无法响应用户的请求，进程的 CPU 占用率一般为零。

一般 JDK 5 以上，线程 Dump中可以直接报告出 Java 级别的死锁

步骤：

1、生成线程转储：jstack -l <pid>。

2、搜索 deadlock 关键字：

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00007f8b4800e800 (object 0x000000076b8a1c98, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00007f8b4800e800 (object 0x000000076b8a1c98, a java.lang.Object),
  which is held by "Thread-1"

3、根据提示修复代码中的锁竞争逻辑。

案例 2：CPU 占用过高

该情况下，一般表现为系统响应慢。

步骤：

1、使用 top 命令，确定占用 CPU 最高的进程ID（PID）。

2、生成线程转储：jstack -l <pid>

3、使用 top -H -p pid 查看该进程中，各线程的CPU 占用情况。

4、上述看到的 PID 其实就是线程 ID，但是是十进制的，使用 printf "%x\n" PID，输出十六进制。

5、在线程转储中搜索该十六进制的线程，定位到问题线程的堆栈：

"WorkerThread" #42 prio=5 os_prio=0 tid=0x00007f8b4800e800 nid=0x3039 runnable [0x00007f8b50a0e000]
   java.lang.Thread.State: RUNNABLE
    at com.example.MyService.cpuIntensiveMethod(MyService.java:100)

6、分析代码逻辑，优化高 CPU 消耗的操作。

7、如果分析代码无法找到高 CPU 的理由时，就需要在一次请求中进行多次 thread dump 文件的转储，做先后对比，如果 runnable 的线程前后差异大，说明系统属于正常情况，是服务器资源不够的问题，需要加大服务器资源。如果是在执行同一个方法，那就说明该方法是有较大可能存在问题，还需要再去分析代码是否有优化的空间。

案例 3：线程长时间阻塞

步骤：

查找处于 BLOCKED 或 WAITING 状态的线程。
分析锁的持有者和等待链：

"DB-Connection-Thread" #5 prio=5 os_prio=0 tid=0x00007f8b4800e800 nid=0x1a03 waiting for monitor entry [0x00007f8b50a0e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.DatabaseService.executeQuery(DatabaseService.java:50)
    - waiting to lock <0x000000076b8a1c98> (a com.example.ConnectionPool)