jstack是JDK自带的轻量级线程诊断工具，用于抓取JVM线程快照以排查死锁、高CPU和阻塞问题；需用jstack -l <pid>开启锁详细模式，搜索“Found one Java-level deadlock”定位死锁，结合top -Hp与nid十六进制匹配定位高CPU线程，通过BLOCKED状态及waiting to lock/locked锁地址关联分析锁竞争。
Java 应用出现响应迟缓、请求堆积或服务假死，往往不是代码逻辑错误，而是线程层面出了问题。jstack 是 JDK 自带的轻量级诊断工具，不需要额外依赖，就能直接抓取 JVM 当前所有线程的状态快照——包括运行栈、锁持有关系、等待目标等关键信息。它不侵入业务，也不需要重启服务，是线上排查死锁和高 CPU 问题的第一步。
快速识别 Java 级死锁
死锁不是靠肉眼比对堆栈发现的，jstack 会自动检测并明确提示：
- 必须使用 jstack -l <pid> 命令，
-l参数开启锁详细模式，否则看不到锁地址和持有者信息 - 生成日志后，直接搜索关键词 Found one Java-level deadlock 或 Deadlock detected
- 若存在死锁，结尾会清晰列出相互等待的线程对，例如：
"Thread-A": waiting to lock <0x000000076b0a1111>, which is held by "Thread-B"
"Thread-B": waiting to lock <0x000000076b0a2222>, which is held by "Thread-A" - 顺着这两个线程名，回溯各自堆栈中带有 - locked <0x...> 和 - waiting to lock <0x...> 的行，就能定位到具体哪两段 synchronized 代码或 ReentrantLock 操作形成了闭环等待
定位 CPU 占用过高的 Java 线程
CPU 飙高常由死循环、密集计算、无界递归或频繁字符串操作引发，单看 jstack 不够，需结合操作系统线程 ID 关联：
- Linux 下执行 top -Hp <pid>，查看进程中各线程的 CPU 使用率，记下高占用线程的十进制 TID（如 13812）
- 将该 TID 转为十六进制（如 13812 → 0x35f4），在 jstack 输出中搜索 nid=0x35f4
- 找到对应线程后，重点看其线程状态是否为 RUNNABLE，再看栈顶方法（如
String.indexOf、HashMap.get、自定义循环体）是否处于持续计算路径 - 常见陷阱：正则匹配超长文本、JSON 反序列化深层嵌套、未设 limit 的 Stream.collect、无限重试逻辑
分析线程阻塞与锁竞争瓶颈
大量线程 BLOCKED 不一定死锁，但会导致吞吐骤降、接口超时，是更常见的性能隐患：
立即学习“Java免费学习笔记（深入）”；
- 搜索 java.lang.Thread.State: BLOCKED (on object monitor)，这类线程正在争抢 synchronized 锁
- 看其栈帧末尾是否有 waiting to lock <0x...>，记下这个锁地址
- 全局搜索该锁地址，找到唯一带有 locked <0x...> 标记的线程——它的调用栈就是阻塞源头
- 典型场景：慢 SQL 持有数据库连接锁太久、IO 流未设置超时、共享对象锁粒度太大（如整个 service 实例加锁）、线程池满导致任务排队等待 worker
辅助验证与日常建议
单一工具易误判，建议组合验证，同时养成规范习惯：
- 配合 jstat -gcutil <pid> 1000 5 观察 GC 是否异常频繁，排除 GC 导致的“伪高 CPU”
- 导出 jstack 日志时建议加时间戳，如
jstack -l 12345 > thread_dump_$(date +%s).txt，便于多份比对 - 生产环境避免直接在终端执行 jstack，应重定向到文件，防止输出截断或终端卡死
- 对高频写操作类服务，考虑用 ReentrantLock.tryLock(timeout, TimeUnit) 替代 synchronized，主动暴露锁等待问题
