JVM故障排查实战指南：jstack深度解析

一、为什么JVM故障排查是开发者的必修课

Java应用在长时间运行后，难免出现响应变慢、请求堆积、CPU飙高乃至服务中断的问题。这些故障不仅拖垮用户体验，还可能造成直接资损。更棘手的是，故障往往发生在生产环境且难以复现，能否在第一时间采集到”现场信息”并快速定位，直接决定了故障恢复速度。

在JVM的诊断工具箱中，jstack是成本最低、上手最快的利器之一：它无需额外安装、对系统侵入性小，一次抓取即可拿到进程内所有线程的调用堆栈与锁信息，是排查CPU飙高、死锁、线程阻塞等问题的首选手段。

二、jstack工具概述与基本用法

jstack是JVM自带的命令行诊断工具，用于为指定的Java进程生成线程快照（thread dump）。其核心能力包括：

• 打印目标进程中每个线程的调用堆栈；
• 输出锁信息：哪个线程持有哪些锁、正在等待哪些锁；
• 配合core file，可分析已崩溃进程的现场。

基本命令格式：

# 输出目标Java进程的线程堆栈
jstack [option] <pid>
# 推荐写法：附加锁信息并落盘，便于多次对比
jstack -l <pid> > thread_dump_1.txt

其中pid为Java进程号，可通过 jps 或 ps -ef | grep java 获得。常见选项说明：

选项	作用
-F	当进程无响应、正常输出请求不被响应时，强制输出线程堆栈
-m	混合模式。若线程调用到本地方法（JNI），同时显示C/C++层面的堆栈
-l	除堆栈外，输出锁的附加信息。发生死锁时，可用 jstack -l pid 观察锁持有情况

实操提示：建议每隔数秒连续抓取3～5次并分别落盘，对比线程状态的变化，这比单次快照更能反映问题本质；同时将输出重定向到文件，避免终端刷屏导致信息丢失。

三、读懂堆栈的前提：线程六大状态

jstack输出的每个线程都带有 java.lang.Thread.State 状态标签，看不懂状态，堆栈就是天书。因此排查前必须先复习六大状态：

1. New：线程对象已创建但尚未调用start()，还未被调度。
2. RUNNABLE：JVM自定义的状态，对应操作系统的Running与Ready。由于CPU在这两个状态间的切换几乎是瞬时的，JVM统一用RUNNABLE表示。注意：处于RUNNABLE的线程不一定在消耗CPU，例如网络IO等待（Socket读写）在JVM视角下同样显示为RUNNABLE，这是很多初学者误判的根源。
3. Waiting：线程处于等待唤醒状态，且无超时机制，需其他线程显式唤醒，典型调用如 Object.wait()、Thread.join()。
4. Timed Waiting：在有限时间内等待唤醒，超时后自动恢复，典型调用如 Thread.sleep(ms)、Object.wait(ms)。
5. Blocked：线程在等待进入同步区域，等待获取监视器锁（monitor lock）。
6. Terminated：线程工作完成，处于结束状态。

状态流转示意：

New --start()--> RUNNABLE
RUNNABLE --wait()/join()/park()--> Waiting --notify()/unpark()--> RUNNABLE
RUNNABLE --sleep(ms)/wait(ms)--> Timed Waiting --超时或唤醒--> RUNNABLE
RUNNABLE --竞争synchronized失败--> Blocked --获取到锁--> RUNNABLE
RUNNABLE --run()结束--> Terminated

四、堆栈文件分析：必须重点关注的关键特征

拿到dump文件后，通过搜索以下关键字可以快速圈定嫌疑线程：

• runnable：线程正在执行中。若多数业务线程长期处于该状态且CPU居高不下，需警惕死循环、大集合全量遍历、低效正则回溯等；
• deadlock：检测到死锁，最高优先级，重点关注；
• blocked / waiting for monitor entry：线程等待获取监视器锁，重点关注。大量线程阻塞在同一把锁上，说明锁竞争激烈或持锁线程执行过慢；
• parked：线程被挂起，常见于线程池空闲工作线程，属正常现象；但若所有工作线程都park且任务队列持续堆积，则是处理能力不足的信号；
• locked / waiting to lock：分别表示”该线程持有某对象的锁”与”该线程正在等待某对象的锁”，二者结合即可还原锁的等待链；
• Object.wait()：线程在对象监视器上等待，常见于各类资源池的空闲等待；
• waiting on condition：线程在等待资源（条件），重点关注。最常见的情况是线程在等待网络读写，如等待数据库响应、下游接口返回。大量出现时，通常指向外部依赖慢或连接池耗尽。

一段典型的阻塞线程堆栈：

"biz-worker-3" #48 daemon prio=5 nid=0x5a2f waiting for monitor entry [0x00007f8a...]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.demo.service.OrderService.process(OrderService.java:88)
    - waiting to lock <0x000000076ab4c3f0> (a java.lang.Object)
    - locked <0x000000076ab4d120> (a java.lang.Object)

解读要点：该线程处于BLOCKED，在等待对象 0x000000076ab4c3f0 的锁，同时自己又持有 0x000000076ab4d120 的锁。在全量dump中搜索”locked <0x000000076ab4c3f0>“即可找到持锁者，从而拼出完整的锁等待链。

五、三大高频实战场景

场景一：CPU使用率飙高（四步定位法）

# 1. 找到占用CPU最高的Java进程
top
# 2. 找到该进程内占用CPU最高的线程
top -Hp <pid>
# 3. 将线程号（十进制）转为十六进制
printf "%x\n" <tid>
# 4. 在堆栈中检索该线程，查看其正在执行的方法
jstack <pid> | grep <hex_tid> -A 30

第4步得到的就是”最耗CPU的那根线程正在执行的代码栈”。栈顶方法通常是热点：可能是死循环、频繁全量扫描等；若栈顶是GC相关线程，则说明瓶颈在内存而非业务代码。验证方式是连续抓取多次堆栈，同一方法始终出现在栈顶即可定罪。

场景二：死锁

典型成因是两个线程以相反顺序获取两把锁：

Object lockA = new Object();
Object lockB = new Object();
// 线程1：先拿A，再要B
new Thread(() -> {
    synchronized (lockA) {
        try { Thread.sleep(1000); } catch (InterruptedException e) {}
        synchronized (lockB) { /* ... */ }
    }
}, "thread-1").start();
// 线程2：先拿B，再要A
new Thread(() -> {
    synchronized (lockB) {
        try { Thread.sleep(1000); } catch (InterruptedException e) {}
        synchronized (lockA) { /* ... */ }
    }
}, "thread-2").start();

执行 jstack -l <pid>，输出末尾会直接给出结论：

Found one Java-level deadlock:
=============================
"thread-2":
  waiting to lock <0x...> (a java.lang.Object),
  which is held by "thread-1"
"thread-1":
  waiting to lock <0x...> (a java.lang.Object),
  which is held by "thread-2"

修复方向：统一加锁顺序、缩小同步范围、改用带超时的tryLock、或将互斥资源的处理收敛到单线程。

场景三：服务无响应但CPU不高

若dump中大量线程处于 waiting on condition，且栈帧停留在数据库驱动或下游调用处，基本可判定为外部依赖超时或连接池耗尽。此时应检查连接池最大连接数、慢查询、下游接口超时设置，并补充熔断与快速失败机制，避免线程被无效等待占满。

六、排查流程总结与最佳实践

将上述内容沉淀为通用流程：

1. 确定现象：CPU高、无响应还是内存异常？现象决定工具组合——CPU问题用jstack配合top，内存问题可配合JDK自带的堆与GC观察工具；
2. 采集现场：第一时间连续抓取线程快照、GC日志与系统指标，现场一旦丢失，排查难度成倍增加；
3. 定位异常线程：通过关键字（deadlock、blocked、waiting on condition）或线程ID（CPU场景）圈定嫌疑线程；
4. 还原等待链：结合locked与waiting to lock分析锁关系，结合线程名判断线程池归属；
5. 核对代码：将堆栈行号与源码对齐，确认业务逻辑后修复；
6. 修复与预防：将线程数、堆内存、GC停顿等指标接入统一的监控告警体系，并补充压测，防止同类问题复发。

预防性建议：给线程池线程命名，堆栈可读性将大幅提升；避免在持有锁的临界区内执行远程调用或IO等耗时操作。

七、结语

jstack虽小，却是JVM故障排查体系中最高频的入口。掌握”线程状态—堆栈特征—实战流程”三层知识后，多数线程相关的线上问题都能在十几分钟内锁定方向。建议在测试环境提前演练文中命令，把工具用法变成肌肉记忆，故障来临时方能从容不迫。