jstack -l 可快速定位Java死锁，输出中“Found one Java-level deadlock”会明确列出互相等待的线程和锁；未发现不代表无死锁，需人工分析BLOCKED线程的locked/waiting to lock地址链。
怎么用 jstack 快速定位死锁
只要 JVM 进程还在运行，jstack 就能直接抓到当前线程快照。它不依赖调试模式，也不需要提前开启任何开关——这是它比 jcmd 或 JMX 更快上手的地方。
执行命令：jstack -l <pid></pid>（-l 是关键，不加就看不到锁持有者和等待者关系）
- 输出里搜
Found one Java-level deadlock，如果有，下面会明确列出互相等待的线程和锁对象 - 没找到不等于没死锁——可能是活锁、自旋等待、或锁被 native 代码持有着，
jstack看不见 - 注意看每个线程的
java.lang.Thread.State：如果大量线程卡在BLOCKED on java.util.concurrent.locks.ReentrantLock$NonfairSync@...，但没标“deadlock”，就得人工顺着locked和waiting to lock对链路
jstack 抓 CPU 飙升线程时为什么常漏掉真凶
CPU 飙升不等于线程在等锁，更多时候是线程在疯狂执行（比如无限循环、正则回溯、GC 频繁）。jstack 只给堆栈快照，看不出 CPU 消耗分布，容易把“跑得最久”的线程误认为“最耗 CPU”的线程。
- 先用
top -H -p <pid></pid>（Linux）或htop找出真实占用 CPU 最高的线程 ID（TID），再转成十六进制 - 用
jstack <pid> | grep <hex-tid> -A 10</hex-tid></pid>定位该线程栈——这才是精准锚点 - 常见陷阱：看到
Unsafe.park就以为是阻塞，其实它也可能出现在CompletableFuture异步回调里，背后是 CPU 密集型计算刚结束 - 如果线程状态是
RUNNABLE但栈顶全是java.util.regex.Pattern或String.indexOf，大概率是正则灾难或字符串暴力匹配
不同 JDK 版本下 jstack 输出差异直接影响判断
JDK 8 和 JDK 11+ 的线程状态标记、锁信息格式、甚至默认是否显示 native 栈都有区别。拿老文档去套新版本，很容易看错锁类型或忽略关键字段。
立即学习“Java免费学习笔记（深入）”；
- JDK 8：
java.lang.Thread.State: WAITING (parking)表示调用了LockSupport.park，但不说明是ReentrantLock还是Condition.await - JDK 11+：增加了
java.lang.Thread.State: WAITING (on object monitor)和(parking)的明确区分，前者对应synchronized，后者才对应LockSupport - JDK 17 开始默认禁用 native 栈（
-m参数才启用），而某些 JNI 调用导致的 CPU 飙升必须靠 native 栈才能发现 - 别信网上“通用解析脚本”——很多自动分析工具硬编码了 JDK 8 的锁格式，在 JDK 17 下会漏掉
jdk.internal.misc.Unsafe.park类型的等待
什么时候 jstack 根本拿不到有用信息
不是所有问题都适合用 jstack。它本质是“静态快照”，对瞬态问题、JVM 底层卡死、或进程已无响应的情况完全失效。
- 进程
kill -3没反应？说明 JVM 线程调度器本身卡住，jstack也发不出请求——这时候只能靠gcore+gdb或jmap -histo看内存分布 - 频繁
OutOfMemoryError: Metaspace？jstack不显示类加载器状态，得配合jstat -gc <pid></pid>和jmap -clstats <pid></pid> - 容器环境下 PID 经常变，
jstack直接报Unable to open socket file——不是权限问题，是 /tmp/.java_pid文件被容器清理掉了，得挂载 /tmp卷或改用docker exec -it <container> jstack ...</container>
真正难的从来不是怎么运行 jstack，而是快照里那一屏堆栈，哪些字段该信、哪些是干扰项、哪些缺失信息必须用别的工具补全。
