StackWalker是Java 9引入的轻量级堆栈遍历API，专为高频采样设计；相比Throwable.getStackTrace()，它支持惰性加载、按需过滤、跳过框架帧且避免大量对象创建，但需显式配置选项（如RETAIN_CLASS_REFERENCE）才能获取完整信息。
StackWalker 是什么，它和 Throwable.getStackTrace() 有什么区别
StackWalker 不是替代 Throwable.getStackTrace() 的“升级版”，而是面向**高开销堆栈采集场景**设计的轻量级 API。它默认跳过中间框架栈帧（比如 java.lang.reflect、jdk.internal），支持懒加载、按需过滤、避免创建大量 StackTraceElement 对象——这对高频日志、性能监控或 AOP 堆栈采样很关键。
常见误区是直接用 StackWalker.getInstance() 就以为能拿到完整调用链，结果发现帧数少、缺类名、甚至抛 SecurityException。
如何正确初始化 StackWalker 并获取当前调用栈
必须显式指定选项，否则默认行为会丢掉你关心的帧。最常用组合是：
-
StackWalker.Option.RETAIN_CLASS_REFERENCE：保留Class引用，后续可调用getClassName()、getMethod()等，否则只能拿到字符串形式的类名 -
StackWalker.Option.SHOW_HIDDEN_FRAMES：显示 JVM 内部帧（如java.base/jdk.internal），调试类加载或反射问题时需要
实操建议：
StackWalker walker = StackWalker.getInstance(
StackWalker.Option.RETAIN_CLASS_REFERENCE,
StackWalker.Option.SHOW_HIDDEN_FRAMES
);
walker.walk(frames -> frames
.limit(10) // 避免全栈遍历拖慢性能
.map(frame -> String.format("%s.%s(%s:%d)",
frame.getClassName(),
frame.getMethodName(),
frame.getFileName(),
frame.getLineNumber()
))
.forEach(System.out::println)
);
为什么 walk() 里拿不到当前方法（即调用 walk() 的那一层）
这是 StackWalker 的**默认行为**：它从调用 walk() 方法的**下一层**开始遍历，也就是跳过了你自己写的那行 walker.walk(...)。这不是 bug，是设计使然——多数场景你关心的是“谁调用了我”，而不是“我在哪调了 walk”。
如果真要包含当前方法，得手动补一层：
- 用
StackWalker.getInstance().getCallerClass()获取上层 Class（JDK 15+），但不带行号/文件名 - 更可靠的做法：在
walk()外先 throw 一个临时Throwable，取其第一个StackTraceElement，再拼接到walk()结果前 - 注意：不要在循环或热点路径里这么做，临时异常开销大
在 JDK 8 或 Android 上无法使用 StackWalker 怎么办
StackWalker 是 JDK 9 引入的，JDK 8 及以下、Android（除非是 Android 13+ ART 支持部分 JDK 9+ API）均不可用。此时唯一兼容方案仍是 new Throwable().getStackTrace()，但要注意：
- 它强制触发完整栈生成，比
StackWalker慢 3–5 倍，且 GC 压力明显 - 所有帧都带完整信息（包括你想过滤掉的
sun.*、java.lang.Thread等），需手动filter掉无关帧 - Android 上某些 ROM 会裁剪栈帧（尤其在 release 模式），
getStackTrace()返回长度可能不稳定
没有银弹——如果项目必须兼容 JDK 8，就老实用 Throwable；如果只跑 JDK 11+ 服务端，优先用 StackWalker 并配好选项。
真正容易被忽略的是：StackWalker 的 walk() 是一次性消费流，不能重复遍历；而且它的 tryAdvance() 在 lambda 中中断后，后续帧不会自动清理，长期持有 walker 实例可能隐式泄露栈帧引用。
