jstack可秒级定位CountDownLatch.await()无限挂起的主线程，通过PID获取、过滤WAITING状态线程及调用栈，结合上下文分析未触发countDown()原因并辅以超时机制止损。
用 jstack 抓住被 CountDownLatch 卡住的主线程，关键不是等它“死锁”——CountDownLatch.await() 本身是阻塞而非死锁，但若 countDown() 永远不被调用，线程就会无限挂起。此时 jstack 能在秒级内定位问题线程状态和调用栈，无需重启、无需埋点。
确认目标 Java 进程 PID
先快速找到出问题的应用进程 ID：
- Linux/macOS 下常用：
ps -ef | grep java或jps -l（需 JDK 的 bin 目录在 PATH 中） - 若应用有明确名称（如
MyService.jar），可用jps -l | grep MyService精准过滤 - 注意区分多个 Java 进程，避免 jstack 错误进程导致无意义快照
执行 jstack 并聚焦 BLOCKED / WAITING 线程
jstack 默认输出所有线程，但 CountDownLatch.await() 阻塞时线程状态为 WAITING (on object monitor)，不是 BLOCKED（后者是 synchronized 竞争锁）：
- 基础命令：
jstack <pid> > thread_dump.txt - 更高效方式（直接过滤）：
jstack <pid> | grep -A 10 -B 5 "await"，快速定位含await()的栈帧 - 重点关注
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:)所在的线程，检查其堆栈是否停留在该行，且上方无countDown()触发逻辑
从线程栈反推业务卡点位置
仅看到 await() 不够，要结合上下文判断为何没被唤醒：
- 看
await()上方几行：是否在某个异步回调、CompletableFuture.thenApply、线程池 submit 后未执行？常见于 ExecutorService 被 shutdown 但任务未完成 - 检查是否有异常吞没：比如
countDown()被包在 try-catch 中，异常抛出后未执行，而 await 线程毫不知情 - 留意 latch 初始化值：若
new CountDownLatch(2)但只调了一次countDown()，线程仍会等待——jstack 无法直接显示 count 值，需结合代码或加临时日志验证
辅助验证与快速止损建议
抓到线索后，别只看堆栈，配合简单手段交叉验证：
- 用
jstat -gc <pid>看是否伴随频繁 GC 或内存打满——有时线程卡住是因系统资源耗尽，而非纯逻辑问题 - 若确认是 latch 未触发，且环境允许，可考虑用
await(long, TimeUnit)替代无参版，加超时主动失败，避免无限挂起 - 上线前用
final CountDownLatch latch = new CountDownLatch(1);+ 显式latch.countDown()调用路径做单元测试覆盖，尤其关注异常分支
不复杂但容易忽略：jstack 是快照，不是实时追踪器。一次抓不到？3 秒内连抓 2–3 次比单次深挖更有效——如果某线程反复出现在 WAITING 状态且栈完全一致，基本就是它了。
