复杂多线程系统里，常见的一种误解是把所有线程卡死都归结为 synchronized 锁竞争。典型的内置锁死锁确实表现为线程状态 BLOCKED，线程转储中能看到两个线程互相占用对方需要的 monitor。但还有一种更隐蔽的情况：线程并没有阻塞在同步锁上，而是停在某个条件等待、计数器、Future.get 或者异步回调上，两个甚至多个线程互相依赖对方的推进，但谁也无法继续。这就是逻辑死锁。
逻辑死锁最大的特点是线程状态往往不是 BLOCKED，而是 WAITING 或 TIMED_WAITING。比如线程 A 在等待线程 B 写入一个标志位，线程 B 又在等待线程 A 先释放某个资源或完成某个步骤。从 jstack 的线程转储看，每个线程都停在看似合理的等待调用上，如果只看单条栈，很难判断异常。需要把多个线程的等待条件和业务调用链串起来分析。
区分这两种死锁很重要，因为排查手段侧重点不同。阻塞死锁通常关注锁对象和 monitor 持有关系；逻辑死锁则要关注线程等待的条件变量、任务队列或者阻塞点。Thread.dumpStack 和 jstack 都能提供线程当前栈帧，但前者适合在代码里主动埋点，后者适合从外部获取全局视图。
一、Thread.dumpStack：在代码关键路径主动输出当前调用栈
Thread.dumpStack 是 Thread 类提供的一个静态方法，调用后会把当前线程的完整调用栈打印到标准错误流。它不需要配合异常对象，也不改变程序执行流程，很适合在怀疑发生逻辑死锁的入口、出口或条件等待前后插入。例如在一个任务提交到线程池之前，或在一个线程进入等待循环之前，调用 Thread.dumpStack 可以记录这条路径是从哪里触发的。
下面是一个简单的埋点示例。假设我们有一个任务分发方法，怀疑某些任务卡在等待结果阶段，可以在进入和离开方法时分别打印调用栈，比较哪些线程只进入了入口却没有出口。
public class TaskService {
public void dispatchTask(String taskId) {
// 入口埋点：记录本次任务由哪个业务线程发起
Thread.dumpStack();
try {
// 模拟复杂业务处理，可能等待其他线程回调
processTask(taskId);
} finally {
// 出口埋点：如果程序能走到这里，说明任务没有卡在前面的等待
System.out.println("task " + taskId + " finished");
}
}
private void processTask(String taskId) {
// 实际的业务逻辑
}
}
使用 Thread.dumpStack 的好处是零配置，不需要额外工具，改代码重新部署后就能看到调用栈。但它有三个局限：一是输出到标准错误流，可能和业务日志混杂；二是只能打印当前线程，无法直接看到其他线程的栈；三是高频调用会显著增加 I/O 开销，不适合在极热路径上埋点。因此它更适合在逻辑分支较少、怀疑点比较明确的位置使用。
另外，Thread.dumpStack 打印的栈信息与 jstack 获取的栈帧格式基本一致，都包含类名、方法名、文件名和行号。这一点很重要，因为后续用 jstack 抓到的线程转储，可以和 Thread.dumpStack 的输出直接对比，确认某个线程是不是就卡在我们埋点的调用链里。
二、jstack：从外部获取进程级线程快照
jstack 是 JDK 自带的命令行工具，可以附加到运行中的 Java 进程，输出所有线程的堆栈跟踪、线程状态以及部分锁信息。对于已经在生产环境运行、不方便重新部署代码的场景，jstack 是最直接的外部诊断手段。基本用法是先通过 jps 或 ps 找到 Java 进程 PID，然后执行 jstack PID。如果进程因为权限问题无法附加，可以加上 -F 参数，但 -F 会走特殊执行路径，有时输出不如正常模式完整。
线程转储里每一条线程记录通常包含线程名、线程 ID、是否 daemon、优先级、线程状态以及栈帧列表。尤其要关注线程状态字段。如果发现多个业务线程都处于 WAITING 或 TIMED_WAITING，而且它们等待的对象或条件互相关联，就很有可能是逻辑死锁。例如一个线程转储片段如下：
"pool-1-thread-1" #12 prio=5 os_prio=0 tid=0x00007f2a3c001000 nid=0x1a3c waiting on condition [0x00007f2a2d5e9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000d5f16a98> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at com.demo.OrderService.waitForPayment(OrderService.java:88)
at com.demo.OrderService.processOrder(OrderService.java:61)
at com.demo.TaskService.dispatchTask(TaskService.java:23)
这段栈显示线程 pool-1-thread-1 正停在 CountDownLatch.await 处，等待一个倒计数。单独看这一条信息，只能知道它在等待，无法判断是否死锁。必须结合其他线程的转储，找到那个本来应该调用 countDown 的线程，看看它又卡在哪里。假如另一个线程 pool-1-thread-2 的栈里也停在某个 CountDownLatch.await 或某个需要回调的阻塞调用上，而两个线程的业务逻辑又互相依赖对方完成一步，逻辑死锁就基本清晰了。
jstack 还支持 -l 参数输出额外的锁信息，比如可重入锁的持有者；使用 jstack -l PID 可以看到更多 java.util.concurrent.locks 包的锁详情。对于逻辑死锁，这些锁信息有时能直接显示某个 ReentrantLock 被哪个线程持有，但如果是条件变量或异步回调造成的死锁，锁信息可能帮助不大，核心还是要分析线程等待的业务条件。
三、结合两种手段定位逻辑死锁的完整流程
在实际排查中，通常先使用 jstack 获取一次或多次线程快照。逻辑死锁的线程状态基本不会变化，所以间隔几秒抓取两次，如果同一批线程始终停在相同的等待调用上，说明这些线程已经卡住。拿到线程栈后，找出所有 WAITING 或 TIMED_WAITING 的业务线程，把它们的栈顶关键行和等待对象标记出来。例如线程 A 停在 CountDownLatch.await，线程 B 停在 Future.get，线程 C 停在 Thread.sleep 等。然后结合业务代码，梳理它们之间的依赖关系。
当通过 jstack 初步锁定几个可疑线程后，可以在对应的入口方法中加入 Thread.dumpStack()，重新触发一次业务流程，观察打印出来的调用链是否与 jstack 抓到的线程栈一致。如果一致，说明这些线程确实进入了这段逻辑，并且没有走完出口。接下来可以继续在更细粒度的方法调用前后埋点，逐步缩小死锁发生的具体步骤。Thread.dumpStack 的输出能精确到行号，帮助定位到某个条件等待语句。
下面给出一个简化的排查命令序列，假设 Java 进程 PID 为 9273：
# 第一次抓取线程快照 jstack -l 9273 > thread_dump_1.txt # 等待 10 秒后再次抓取 sleep 10 jstack -l 9273 > thread_dump_2.txt # 比较两次文件中处于 WAITING 的线程是否相同 grep "java.lang.Thread.State: WAITING" thread_dump_1.txt grep "java.lang.Thread.State: WAITING" thread_dump_2.txt
需要注意的是，逻辑死锁不一定会被 jstack 标记为 Deadlock。jstack 自带的死锁检测主要针对 synchronized 内置锁，如果是 java.util.concurrent 包下的锁或线程间条件依赖，它可能只显示线程处于等待状态，不会给出明显的死锁提示。因此不能只依赖 jstack 的自动检测结果，必须人工分析线程栈。
另外，使用 Thread.dumpStack() 时建议配合日志框架记录时间戳和线程名，因为标准错误流的输出顺序不一定与调用顺序完全一致。可以在调用前先打印一条带业务标识的日志，例如 logger.info("before dispatch, thread={}", Thread.currentThread().getName())，这样在大量输出中更容易匹配。定位到死锁后，通常需要修改业务设计，例如合并等待点、设置超时、使用消息队列解耦依赖，或者用 CompletableFuture 明确编排任务依赖关系。
Thread.dumpStackjstack逻辑死锁修改时间：2026-09-22 03:27:57