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