JVM 故障排查实战指南：线程堆栈深度解析

一、排查思路总览：先归类症状，再选择工具

线上 Java 应用的故障虽然表象各异，但归纳起来基本落在四个资源维度：CPU、内存、线程与外部 IO。动手之前先花一分钟对症状归类，能避免盲目敲命令浪费时间：

• CPU 飙高：多半指向计算密集型代码缺陷，如死循环、正则回溯、大集合频繁遍历、序列化热点等；
• 内存异常：堆内存持续增长、Full GC 频繁甚至发生内存溢出，通常需要转向内存快照分析方向；
• 响应缓慢但资源平稳：线程大量阻塞在锁、外部调用或网络 IO 上，这是线程堆栈分析的主战场；
• 整体无响应：需高度怀疑死锁或线程池耗尽。

JDK 自带的命令行诊断工具基本能覆盖上述场景：用 jps 列出目标 Java 进程，用 jstat 观察 GC 行为，用 jmap 导出内存快照，用 jstack 导出线程堆栈。其中 jstack 是线程类问题的核心武器，也是本文的重点。

二、jstack 工具详解

2.1 它能做什么

jstack 用于生成指定 Java 进程在某一时刻的线程堆栈快照（thread dump），输出内容包括：每个线程当前执行的方法调用链、线程持有的锁、正在等待的锁以及线程当前状态。它相当于给进程内所有线程拍了一张“X 光片”，是定位死锁、锁竞争、线程阻塞与 CPU 热点的第一手数据。

2.2 基本用法与常用选项

最常用的命令形式如下：

# 打印对应 Java 进程的线程堆栈
jstack [option] <pid>

常用的三个选项：

• -F：当目标进程无响应、正常的堆栈请求不被应答时，强制输出线程堆栈；
• -m：若调用链中涉及本地方法（JNI），可同时显示 C/C++ 层的堆栈，用于排查 native 代码问题；
• -l：除堆栈外附加输出锁的持有信息，这是排查死锁时的标准姿势，能清楚看到每个线程持有哪些锁、又在等待哪些锁。

2.3 采集堆栈的三种途径与采样技巧

1. 对存活进程直接执行 jstack pid，最常用；
2. 进程崩溃但有 core file 时，可基于核心转储文件离线分析堆栈；
3. 进程已无响应、远程连接不稳定时，可向进程发送 kill -3 信号，JVM 会将线程堆栈输出到标准输出日志中。

需要特别强调：堆栈是某一瞬间的切面，单次快照很容易误判。规范做法是间隔 3~5 秒连续采集 3~5 次，横向对比，只关注多次快照中反复出现的共同特征，才能区分偶发现象与持续性问题。

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

3.1 六大状态详解

Java 线程定义了六种状态：

• New：线程对象已创建但尚未调用 start() 启动；
• RUNNABLE：JVM 自定义的状态，对应操作系统的 Running 与 Ready。由于 CPU 在两者之间的切换几乎瞬时完成，JVM 统一用 RUNNABLE 表示；
• Blocked：线程等待进入同步区域、等待获取监视器锁时所处的阻塞状态；
• Waiting：无限期等待，需要其他线程显式唤醒，典型触发点为 Object.wait()（不带超时）、Thread.join()、LockSupport.park()；
• Timed Waiting：有限时间内等待唤醒，典型触发点为 Thread.sleep(ms)、Object.wait(ms) 等带超时参数的调用；
• Terminated：线程执行完毕，进入结束状态。

状态流转可以概括为：New 经 start() 进入 RUNNABLE，RUNNABLE 与 Blocked、Waiting、Timed Waiting 之间因锁竞争或主动等待而切换，最终随 run() 结束进入 Terminated。

3.2 两个容易踩坑的认知

第一，RUNNABLE 不等于“正在消耗 CPU”。阻塞在 socket 读写上的线程，在 JVM 视角下同样显示为 RUNNABLE，因为从 JVM 看来它“随时可被调度”。判断线程是否真在干活，必须结合堆栈内容而非只看状态标签。

第二，Waiting 不一定是问题。线程池中的空闲工作线程通常以 parked/waiting 形式挂起，属于健康状态。判断异常的关键不是单个线程的状态，而是“大量线程处于同一状态且堆栈指向同一处代码”。

四、堆栈文件中的关键信号

拿到 dump 文件后，应优先全文检索以下关键字：

• deadlock：死锁，最高优先级处理。JVM 通常会在堆栈头部直接输出 Found one Java-level deadlock 及死锁环的完整描述；
• blocked / waiting for monitor entry：线程在等待进入同步块、获取监视器锁。少量出现属正常，大量集中出现则说明锁竞争激烈；
• locked：该线程当前持有了某个对象的锁；
• waiting to lock：该线程正在等待某个对象的锁。与 locked 关键字交叉比对，即可还原“谁持锁、谁等锁”的全貌；
• Object.wait()：线程执行了 wait() 进入对象等待，常见于连接池、任务队列的等待逻辑；
• parked：线程被挂起，线程池空闲线程与并发锁框架的底层实现都会出现，需结合业务语义判断是否异常；
• waiting on condition：线程在等待条件资源，最常见的情况是等待网络读写——如数据库查询尚未返回、HTTP 调用下游服务尚未响应。当几十上百个线程集中处于该状态且堆栈指向同一段网络调用代码时，基本可以锁定瓶颈在下游依赖。

五、四个典型场景的完整打法

5.1 场景一：CPU 使用率飙高

# 1. 定位占用 CPU 最高的 Java 进程
top
# 2. 查看进程内各线程的 CPU 占用情况
top -Hp <pid>
# 3. 将目标线程号转为十六进制（堆栈中的 nid 为十六进制）
printf '%x\n' <tid>
# 4. 从堆栈中提取对应线程，查看其正在执行的方法
jstack <pid> | grep '0x<十六进制tid>' -A 30

思路说明：线程号必须转成十六进制，因为堆栈中用 nid 标识线程。-A 30 会输出匹配行之后的 30 行调用链，正在执行的方法就在调用栈顶部。多数情况下可定位到死循环、频繁正则匹配、大集合遍历或序列化热点代码。若对比多次快照发现最耗 CPU 的其实是 GC 线程，则问题方向应转向内存：用 jstat 观察 GC 频率，用 jmap 导出堆快照分析对象构成。

5.2 场景二：死锁

特征是应用部分功能整体无响应且永不自愈。使用 jstack -l pid 采集堆栈分析：

• 堆栈头部出现 Found one Java-level deadlock 字样，并列出互相持有、互相等待的线程与锁对象；
• 在线程堆栈中可以看到两个线程各自 locked 一个对象、同时 waiting to lock 对方持有的对象，形成等待闭环。

处置上，死锁无法自愈，线上只能通过回滚或重启恢复；根治必须回到代码层：统一加锁顺序、缩小锁的持有范围、使用带超时的锁获取方式，避免在持锁状态下发起外部调用。

5.3 场景三：接口变慢，大量 Blocked

当堆栈中出现成片的 blocked / waiting for monitor entry，且等待的是同一个 locked 对象时，说明锁竞争已成为吞吐瓶颈。常见根因包括：粗粒度的 synchronized 方法（如全局缓存刷新、全局配置更新）、临界区内包含数据库访问或文件 IO 等慢操作。优化方向包括：缩小临界区范围、改用读写锁或分段锁、用原子类与 CAS 消除锁、将临界区内的慢操作异步化外移。

5.4 场景四：下游依赖拖慢整体

特征为大量线程 waiting on condition，堆栈指向获取数据库连接、等待下游 HTTP 响应等位置。此时重点核对三件事：连接池大小与超时配置是否合理、下游服务是否出现性能劣化、是否存在重试风暴放大调用压力。代码层面必须为所有外部调用设置超时与失败兜底策略，避免一个依赖拖垮整个进程。

六、把经验沉淀为可复用的方法论

1. 先归类再动手：按 CPU、内存、线程、IO 四个维度确定排查方向，避免命令乱敲、现场丢失；
2. 多次采样对比：单次快照只代表瞬间，间隔采集多次取共性特征，才能还原真实瓶颈；
3. 保留故障现场：条件允许时同时采集线程堆栈、堆快照与系统指标，事后再做交叉分析；
4. 善用云平台能力：在百度智能云等云环境中运行的 Java 应用，可配合平台提供的监控告警、日志服务等通用能力，对 CPU、内存、GC、接口耗时等指标配置阈值告警，借助日志聚合快速缩小问题范围，形成“告警触发—现场采集—堆栈定位”的闭环；
5. 复盘重于修复：死锁、锁竞争类问题必须回到代码层根治，每一次线上故障都应沉淀为编码规范与演练案例。

七、总结

JVM 故障排查的本质是一条“证据链”推理过程：先按症状把问题归入 CPU、内存、线程、IO 中的某一域，再用对应工具采集证据。线程域的证据就是线程堆栈——先读状态（理解六大状态的含义与陷阱），再扫关键字（deadlock、blocked、waiting on condition 等），最后结合调用栈与业务代码收敛到具体方法。jstack 这类 JDK 自带工具轻量、零依赖、随取随用，是每一位 Java 开发者都应熟练掌握的基本功。掌握本文的思路与套路后，绝大多数线程类线上故障都能在几分钟内定位到代码级根因。