jstack 是排查 JVM 线程死锁最直接轻量的工具，能自动标记 Found one Java-level deadlock 并输出锁持有与等待关系，需提取线程名、持有锁、等待锁三要素，结合堆栈定位阻塞代码行及加锁顺序不一致问题。
当 JVM 中出现线程死锁时，jstack 是最直接、最轻量的排查工具。它能快速输出当前所有线程的状态，并在检测到 Java 层死锁时，自动在日志末尾标记 Found one Java-level deadlock，并附上涉及线程的完整锁持有与等待关系。关键在于：不是只看“有无 deadlock”，而是要准确提取出每个线程的调用链、所持锁、等待锁及阻塞位置。
定位 jstack 输出中的 deadlock 区块
执行 jstack -l <pid> > jstack.log</pid> 后，打开日志文件，直接搜索 Found one Java-level deadlock。该提示之后的内容即为死锁分析区块，结构固定：
- 第一行是提示语（如
Found one Java-level deadlock:） - 接下来是若干段以
"Thread-xx"开头的线程描述块 - 每块包含
java.lang.Thread.State: BLOCKED、- waiting to lock、- locked等关键行 - 末尾会总结锁依赖环，例如：
Java stack information for the threads listed above:
提取每个死锁线程的三要素：线程名、持有锁、等待锁
对每个被标记为 deadlock 的线程，需明确抓取三项信息：
-
线程名：位于双引号内，如
"pool-1-thread-2"，是日志中唯一的线程标识 -
持有锁：找
- locked行，记录锁对象地址（十六进制） -
等待锁：找
- waiting to lock行，该地址正是另一线程持有的锁
注意：多个线程之间通过“等待→持有”形成闭环。比如 A 等待 B 持有的锁，B 又等待 A 持有的锁——这就是典型的两线程死锁。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
还原调用链：从 stack trace 定位阻塞点代码行
在 deadlock 区块下方，Java stack information for the threads listed above: 之后会逐个列出各线程的完整堆栈。重点关注：
- 最顶部的
at xxx.xxx.Xxx.method(Xxx.java:NN)—— 这是线程实际卡住的位置（即尝试获取锁但失败的那一行） - 查找该行附近是否有
synchronized块、ReentrantLock.lock()或wait()等同步操作 - 结合源码确认：该方法是否同时持有多把锁？加锁顺序是否不一致？例如线程1先锁 A 再锁 B，线程2先锁 B 再锁 A
示例片段：at com.example.Service.updateOrder(Service.java:42)<br>
- waiting to lock <0x000000071a2b3c5e> (a java.lang.Object)<br>
at com.example.Service.processPayment(Service.java:28)<br>
- locked <0x000000071a2b3c4d> (a java.lang.Object)
说明：该线程在 updateOrder 第42行试图获取锁 0x5e，但已被其他线程占用；同时它已在 processPayment 第28行持有了锁 0x4d。
交叉验证锁地址与对象类型，缩小问题范围
仅靠地址不够直观，需回溯该锁对象在堆栈中首次出现的位置，判断其来源：
- 若锁是
java.lang.Object实例，查new Object()或成员变量初始化位置 - 若锁是
java.util.concurrent.locks.ReentrantLock，找lock.lock()调用及其作用域 - 若锁是类实例（如
com.example.Order@1a2b3c），检查该对象是否被多处作为同步监视器使用
特别注意：同一把锁被不同线程以不同方式（synchronized vs Lock）竞争，不会导致 JVM 死锁检测触发，但可能引发逻辑阻塞——这类情况 jstack 不会标为 “Java-level deadlock”，需另行分析。
