jstack -l <pid>可直接识别Java级死锁，输出首部出现“Found one Java-level deadlock”即确认存在；若无此提示，则非JVM能判定的经典双向等待型死锁。
jstack 能直接识别并报告 Java 级别死锁，不需要人工比对锁地址 —— 但前提是必须用 -l 参数，否则可能漏掉关键线索。
怎么快速确认进程是否存在死锁
执行 jstack -l <pid> 后，如果 JVM 检测到死锁，输出最上方会明确出现类似这样的段落：
Found one Java-level deadlock: ============================= "pool-1-thread-2": waiting to lock monitor 0x00007fbcdf121a88 (object 0x00000000f0c72bb8, a java.lang.Class), which is held by "pool-1-thread-1" "pool-1-thread-1": waiting to lock monitor 0x00007fbcdf1219d8 (object 0x00000000f0c72bc0, a java.lang.Object), which is held by "pool-1-thread-2"
这个区块是 JVM 自动分析的结果，可信度高；没看到它，不代表没有死锁，但至少不是 JVM 能直接判定的“经典双向等待”类型。
-
-l是必须的：它让 jstack 输出锁的详细持有/等待关系，缺了就看不到waiting to lock和locked的对应链条 - 不要依赖
jstack <pid> | grep deadlock：死锁提示只在开头固定位置，grep 容易错过 - 如果进程无响应，加
-F强制 dump（需 root 权限），但输出可能不完整
怎么定位“疑似死锁”但没被自动报告的线程
有些场景（比如三方库用 Lock.lockInterruptibly()、或锁嵌套过深）不会触发 JVM 死锁检测器，但线程已长期 BLOCKED 或 WAITING。这时要手动筛查：
立即学习“Java免费学习笔记（深入）”；
- 先用
jps -l找到目标进程 PID - 运行
jstack -l <pid>，重点关注状态为BLOCKED的线程，它们通常卡在synchronized块入口 - 对每个
BLOCKED线程，记下它 waiting to lock 的对象地址（如0x00000000f0c72bb8），再全局搜索谁 locked 了同一地址 - 用
jstack -l <pid> | grep -A 5 -B 5 '0x[0-9a-f]+'快速定位相关线程上下文
为什么 jstack 输出里看不到线程名或业务方法
常见于以下情况：
- 线程是通过
Executors.newCachedThreadPool()创建且未显式命名：jstack 显示为pool-1-thread-N，需结合代码中 submit 的 Runnable/Callable 类型反推 - 堆栈被 native 方法截断（如
Unsafe.park）：加上-m参数可显示 C/C++ 栈帧，但输出更冗长，一般用于排查 JVM 底层阻塞 - 应用用了字节码增强（如某些 AOP 框架）：实际调用链可能跳过中间层，需对照源码和日志中的 traceId 辅助定位
生产环境执行 jstack 的关键约束
jstack 会触发 JVM 的 safepoint，导致所有应用线程短暂暂停（通常毫秒级），但高并发场景下仍可能引发请求超时。务必注意：
- 避免在流量高峰执行，尤其不能对
-Xms == -Xmx且堆接近满的进程反复 dump - 不要用
jstack <pid> > dump.log直接重定向大文件到磁盘根分区：dump 文件可能达百 MB，填满/会导致系统异常 - 如果需要持续监控，改用
jcmd <pid> VM.native_memory summary或 Prometheus + JMX，而非轮询jstack
真正难的不是跑出 dump，而是从几百个线程里快速锁定那两三个互相掐住脖子的 —— 多练几次 grep 'waiting to lock' 和 grep 'locked' 的组合技，比背参数有用得多。
