Thread.dumpStack() 直接输出到 stderr 且返回 void，无法获取字符串；需用 new Throwable().getStackTrace() 获取可控栈帧数组，注意其只打印当前线程栈、不适用于生产日志。
Thread.dumpStack() 会直接输出到 stderr，不是返回字符串
很多人以为 Thread.dumpStack() 能拿到调用栈内容做日志或分析，其实它只是调用 System.err.println() 打印到标准错误流，不返回任何值（void）。想捕获栈信息必须换方式。
- 调试时临时加一句
Thread.dumpStack()看当前线程在哪卡住，没问题 - 但不能用于记录日志、上报异常或做条件判断——它不产生可编程的数据
- 如果 stderr 被重定向或关闭（比如某些容器环境），你可能根本看不到输出
替代方案：用 Throwable.getStackTrace() 拿可控的栈帧数组
真正需要“获取”调用链路时，应该创建一个 Throwable 实例并调用 getStackTrace()。它返回 StackTraceElement[]，每个元素含类名、方法名、行号等，可自由处理。
-
new Throwable().getStackTrace()开销比dumpStack()略大，但现代 JVM 优化后差异极小 - 注意不要在高频循环里反复调用，避免 GC 压力；单次诊断性打印无压力
- 如果只要当前方法名和行号，用
new Throwable().getStackTrace()[0]就够了
StackTraceElement[] trace = new Throwable().getStackTrace();
for (StackTraceElement e : trace) {
System.out.println(e.getClassName() + "." + e.getMethodName() + ":" + e.getLineNumber());
}
常见误用：在多线程里调用 dumpStack 却看不到预期线程的栈
Thread.dumpStack() 总是打印**当前执行线程**的栈，不是你想象中“目标线程”的。想看其他线程状态，得用 Thread.getAllStackTraces() 或 JMX。
- 比如在主线程里写
otherThread.dumpStack()—— 这会报错，因为dumpStack()是静态方法，没有实例方法版本 - 想 dump 某个线程，只能让它自己执行
Thread.dumpStack()，比如通过submit(() -> Thread.dumpStack()) - 更稳妥的做法是用
ThreadMXBean获取所有线程快照：ManagementFactory.getThreadMXBean().dumpAllThreads(false, false)
生产环境慎用：dumpStack 无法控制输出格式和目的地
它硬编码写死到 System.err，不走日志框架，无法按级别过滤、加前缀、异步刷盘，也不支持 MDC 上下文。上线后容易污染日志、干扰监控。
立即学习“Java免费学习笔记（深入）”；
- 开发阶段快速定位问题可以，但别留在代码里随发布走
- CI/CD 流水线或 APM 工具（如 SkyWalking）已能自动采样慢调用栈，比手动 dump 更可靠
- 如果真要保留栈信息，优先用 SLF4J 的
logger.debug("here", new Throwable())，让日志框架统一处理
dumpStack 自己的调用位置，而不是业务逻辑入口。要往上翻才能找到真正关心的那层调用——这点在嵌套回调或代理增强（比如 Spring AOP）场景下特别容易看错。 
