StackWalker 在 JDK 9+ 中仅在严格配合 skip()、limit() 和 RETAIN_CLASS_REFERENCE 时才比 getStackTrace() 开销更低；否则因全栈遍历、类加载或符号解析反而更慢。
StackWalker 在 JDK 9+ 中确实能比 Thread.getStackTrace() 或 new Throwable().getStackTrace() 更低开销地获取调用栈，但“极低开销”是有前提的——它取决于你怎么用、取多少帧、要哪些字段。
直接结论：只在必要时用 StackWalker.Option.RETAIN_CLASS_REFERENCE，且必须配合 walk() + limit() 控制帧数，否则开销不比老方法小。
为什么 StackWalker 不一定比 getStackTrace() 快
很多人默认 StackWalker 就是“更快的栈遍历”，其实它快的前提是「按需加载」和「延迟解析」。一旦你要求全部帧、全量信息（比如每帧都调用 getClassName() + getMethodName() + getLineNumber()），JVM 就得做类加载、符号解析、行号表查找，开销反而可能更高。
-
Thread.getStackTrace()返回的是已解析好的StackTraceElement[]，但它是全量快照，不管你要不要第 10 层 -
StackWalker.walk()是惰性流式处理，但如果你写s.forEach(...)或没加limit(n)，底层仍会遍历完整栈（尤其在深度递归或框架代理多的场景下） - 默认构造的
StackWalker.getInstance()不带任何Option，此时frame.getDeclaringClass()返回null，getLineNumber()可能为 -1 —— 看似“快”，实则拿不到关键信息，白走一遭
如何用 walk() + limit() 精确控制栈帧数量
最常见需求是“取最近 3 层调用者”，比如日志埋点、权限校验、AOP 切面判断。这时必须显式限制帧数，否则流可能拉取几十甚至上百帧（Spring Boot 启动栈常超 50 层）。
正确写法示例（取最多 3 层真实业务调用帧，跳过当前方法和 lambda 匿名类）：
String[] callerInfo = StackWalker.getInstance(
StackWalker.Option.RETAIN_CLASS_REFERENCE
).walk(s -> s.skip(2).limit(3).map(frame ->
frame.getClassName() + "." + frame.getMethodName() + ":" + frame.getLineNumber()
).toArray(String[]::new));
-
skip(2)：跳过当前方法本身、以及walk()内部的 lambda 匿名类帧（这是硬规则，不 skip 就拿不到真实调用者） -
limit(3)：强制终止流，避免后续帧被计算 —— 这是控制开销的核心，limit()能让 JVM 提前停止栈遍历 - 不要用
findFirst()后再map()，那样只拿 1 帧；也不要省略limit()依赖skip()配合forEach()，那会遍历到底 - 如果只要类名和方法名，不关心行号，可去掉
getLineNumber()调用，减少符号表查找压力
RETAIN_CLASS_REFERENCE 是性能与功能的分水岭
这个选项不是“可选优化”，而是“能否拿到类对象”的开关。没有它，frame.getDeclaringClass() 永远返回 null，连反射、注解扫描、模块权限检查都做不了。
- 开启后：支持
frame.getDeclaringClass()、StackWalker.getCallerClass()，但会触发类加载器查找，有微小延迟 - 关闭后：所有类相关字段不可用，但
getClassName()和getMethodName()仍可用（字符串形式），适合纯日志打点 - 注意：
RETAIN_CLASS_REFERENCE不影响getFileName()或getLineNumber()，这两者依赖 class 文件的调试信息（编译时不能加-g:none） - 在 GraalVM native-image 或某些裁剪 JDK 场景下，该选项可能被禁用或行为异常，需实测验证
Lambda 和匿名类帧会让调用链识别失真
当调用链中存在 Lambda（如 list.forEach(x -> ...)），frame.getClassName() 返回的是类似 MyService$$Lambda3/0x00000008000a0000 的合成类名，getMethodName() 固定是 apply 或 run —— 无法对应源码位置。
- 可靠做法是优先用
frame.getFileName()+frame.getLineNumber()定位，它们在调试信息存在时稳定准确 - 若必须靠类名过滤（比如只接受
com.example.*下的调用），建议结合frame.getDeclaringClass().getSimpleName()做粗筛，而非匹配完整合成类名 - 避免在高频路径（如 Netty I/O 线程、HTTP 请求拦截器）中对 Lambda 帧做正则匹配或字符串
contains()，合成类名无规范，JVM 实现可能变更
真正容易被忽略的点是：StackWalker 的“低开销”不来自 API 本身，而来自你是否严格控制了 skip/limit/option 三者的组合。漏掉任意一个，就可能从毫秒级退化到几十毫秒，尤其在线程栈深、类加载慢、调试信息缺失的生产环境。
