jstack是jdk自带的线程快照工具，用于排查死锁、阻塞和cpu飙升问题；需先用jps -l获取pid，再执行jstack -l 导出含锁信息的快照，其结尾自动检测并标注found 1 deadlock。
jstack 是 JDK 自带的命令行工具，用于打印指定 Java 进程的线程快照（thread dump），是排查死锁、线程阻塞、CPU 占用高等问题的关键手段。它能清晰显示每个线程的状态、锁持有/等待关系，对定位死锁尤其有效。
确认目标 Java 进程 PID
先通过 jps -l 或 ps aux | grep java 找到目标进程的 PID（进程 ID）：
- jps -l 列出所有 Java 进程及其主类或 JAR 路径，适合开发环境
- jps -lv 还会显示 JVM 启动参数，有助于判断是否启用了调试或监控选项
- 若进程运行在容器中，需先进入容器再执行 jps；若无 jps，可用 ps -ef | grep java 配合 awk '{print $2}' 提取 PID
用 jstack 导出线程堆栈（含死锁检测）
直接运行以下命令即可生成完整线程快照，并自动检测是否存在死锁：
-
jstack
> thread_dump.txt —— 将全部线程信息保存到文件，便于分析 -
jstack -l
—— -l 参数必须加上，它会输出锁的详细信息（包括可重入锁、Condition 等），是识别死锁的必要条件 -
jstack -l
| grep -A 10 -B 10 "deadlock" —— 快速定位死锁段落（jstack 在检测到死锁时会在输出末尾显式标注）
从输出中识别死锁的关键特征
死锁在 jstack 输出中表现为一组线程互相等待对方持有的锁，典型结构如下：
- 每条线程状态为 BLOCKED (on object monitor) 或 WAITING (parking)
- 出现类似 waiting to lock (a java.lang.Object) 和 locked (a java.lang.Object) 的成对描述
- jstack 结尾处有明确提示：Found 1 deadlock.，随后列出所有卷入死锁的线程及锁依赖链
- 注意：仅靠线程状态为 BLOCKED 不代表死锁，必须存在循环等待关系（如 Thread-A 等 Thread-B 的锁，Thread-B 又等 Thread-A 的锁）
辅助排查与注意事项
单次 jstack 只是瞬时快照，建议结合多次采样和上下文分析：
- 连续执行 2~3 次 jstack -l
（间隔 2~5 秒），对比线程状态是否持续 BLOCKED，排除临时竞争 - 确保运行 jstack 的用户与目标 Java 进程属同一用户（Linux 下权限不匹配会导致“Unable to open socket file”错误）
- 若进程已挂起或响应缓慢，仍可尝试 jstack；但若 JVM 完全卡死（如 GC 崩溃），jstack 可能无法连接，此时需配合 jmap 或系统级工具（如 gdb）进一步分析
- 生产环境慎用频繁 jstack（虽开销小，但高频采集可能干扰 JVM 内部同步），建议配合 APM 工具（如 Arthas、SkyWalking）做长期监控
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
