Thread.getAllStackTraces()返回Map，键为活跃线程对象，值为其堆栈跟踪快照数组；该映射仅包含RUNNABLE、BLOCKED等非终止状态线程，不包含NEW和TERMINATED线程。
Thread.getAllStackTraces() 返回的是什么结构？
返回一个
，键是当前活跃的
实例（注意：不包含已终止线程），值是该线程最近一次执行时的栈帧数组。它不是实时“抓取”每个线程当前 CPU 指令位置，而是触发 JVM 对每个线程做一次快照 —— 这个快照在多线程环境下可能略有延迟，但对诊断卡死、死锁、高 CPU 占用足够有效。
常见误解是认为它能拿到 native 方法或 JIT 优化后丢失栈信息的线程；实际上，只要线程处于 RUNNABLE 或 BLOCKED 状态，JVM 就能提供 Java 栈，但若线程正深陷 native 调用（如
底层调用
），栈顶可能只显示
或类似占位符。
为什么直接遍历 Map 可能漏掉关键线程？
返回的
只包含「活跃线程」，即
为
、
、
、
的线程。但以下情况容易被忽略：
状态线程（已创建但未 start）不会出现在结果中
线程彻底消失，不可能被捕捉
某些线程（如 ForkJoinPool 的 worker）可能短暂处于
但栈为空数组（
长度为 0），需额外判空
如果线程刚进入
但尚未执行第一行 Java 代码，栈可能极短甚至只有
所以不能只依赖
判断线程总数，更稳妥的方式是配合
和
做交叉验证（后者可捕获 NEW 线程，但需传入足够大的数组）。
如何安全打印所有栈而不阻塞或抛异常？
直接遍历并调用
或
是安全的，但有两点必须处理：
某些线程（如 JVM 内部的
、
）可能拒绝提供栈（返回
），需判空再访问
打印过程中线程可能已退出，导致
键变“悬空”，但
本身是快照，不会并发修改，所以遍历时无需同步
推荐写法：
和 jstack 或 JMX 的对比：什么时候该用 getAllStackTraces()？
它适合嵌入到应用内部做轻量级自检，比如暴露一个 HTTP endpoint 触发 dump，或在 OOM 前自动保存现场。相比
：
不需要外部进程权限，纯 Java API，无 shell 依赖
不会因目标 JVM 挂起而失败（
在严重卡顿时可能连不上）
但无法获取 native 栈、内存映射、锁持有关系等完整信息 —— 它只是 Java 层快照
若需持续监控，别高频调用（每次触发全局 safepoint，影响吞吐），建议间隔 ≥5 秒
真正容易被忽略的是：这个方法在某些容器化环境（如 OpenJ9 + Alpine）或启用了
的 JVM 中，可能被禁用或返回空 Map —— 务必先在目标环境中实测是否生效。
Thread.getAllStackTraces()MapThreadObject.wait()pthread_cond_waitUnsafe.parkMapThread.StateRUNNABLEBLOCKEDWAITINGTIMED_WAITINGNEWTERMINATEDWAITINGStackTraceElement[]run()Thread.run()map.size()Thread.activeCount()Thread.enumerate()thread.getName()stackTrace.lengthSignal DispatcherCommon-CleanernullstackTraceThreadMapMap traces = Thread.getAllStackTraces();
for (Map.Entry entry : traces.entrySet()) {
Thread t = entry.getKey();
StackTraceElement[] stack = entry.getValue(); // 可能为 null
System.out.println("Thread: " + t.getName() + " [" + t.getState() + "]");
if (stack != null) {
for (StackTraceElement e : stack) {
System.out.println("\tat " + e);
}
} else {
System.out.println("\t[no stack trace available]");
}
} jstack jstack-XX:+UnlockDiagnosticVMOptions -XX:+DisableAttachMechanism