Thread.getAllStackTraces() 返回 Map<Thread, StackTraceElement[]>，仅含活跃线程的当前调用栈快照，不含线程状态；需配合 getState() 获取状态，且存在线程终止导致异常、栈为空不表示挂起等问题，生产环境慎用因引发全局停顿。
Thread.getAllStackTraces() 返回的是什么，不是线程状态
它返回的是 Map<thread stacktraceelement></thread>，只包含每个活跃线程的**当前调用栈快照**，不包含 Thread.State（如 RUNNABLE、WAITING 等）。想看状态必须额外调用 thread.getState()。直接遍历结果得不到“线程卡在哪、是不是死锁”这类信息，容易误以为它能替代 ThreadMXBean。
正确获取线程名 + 状态 + 栈帧的组合方式
不能只靠 getAllStackTraces()，得配合 Thread.getThreadGroup().enumerate() 或更稳妥的 ManagementFactory.getThreadMXBean()。但若坚持用前者，需手动补状态：
- 先调用
Thread.getAllStackTraces()拿到所有活跃线程的栈数组 - 对每个
Threadkey 调用thread.getState()获取真实状态 - 注意：某些线程可能在调用过程中已终止，
getState()会抛IllegalThreadStateException，需 try-catch - 栈数组为空（
length == 0）不代表线程挂了，可能是刚启动或处于 native 状态（如WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject）
调试时打印的实用模板（避免日志爆炸）
直接 System.out.println(map) 会触发所有 StackTraceElement.toString()，输出冗长且不可读。建议按需格式化：
Map<Thread, StackTraceElement[]> traces = Thread.getAllStackTraces();
for (Map.Entry<Thread, StackTraceElement[]> entry : traces.entrySet()) {
Thread t = entry.getKey();
StackTraceElement[] stack = entry.getValue();
System.out.printf("[%s] %s — %s%n",
t.getName(),
t.getState(),
stack.length > 0 ? stack[0].toString() : "no stack"
);
}
这样一眼能看出哪些线程停在 Object.wait()、哪些卡在 LockSupport.park()，比全栈更聚焦。
立即学习“Java免费学习笔记（深入）”；
为什么生产环境慎用，以及替代方案
getAllStackTraces() 是全局 stop-the-world 操作：JVM 需暂停所有线程来采集快照，线程越多、栈越深，耗时越明显（尤其在 GC 频繁时）。线上用它查问题可能加剧延迟甚至触发超时。
- 排查死锁？用
ThreadMXBean.findDeadlockedThreads()，开销低且精准 - 看线程状态分布？用
ThreadMXBean.getThreadInfo(ids, 0)（0 表示不采栈），避免无谓开销 - 需要完整栈且接受短暂停顿？改用
jstack <pid>，它底层调用的是更优化的 VM 接口
真正容易被忽略的点是：getAllStackTraces() 不包含已终止但尚未被 GC 的线程（比如刚 join() 完的），也不包含守护线程中的某些 JVM 内部线程（如 Reference Handler），别把它当线程全景图用。
