fillinstacktrace 是性能黑洞，因遍历栈帧、生成字符串、填充数组而高耗 cpu 与内存；高频业务异常应禁用，如 404、配置缺失等，可通过重写方法或构造参数关闭。
fillInStackTrace 为什么是性能黑洞
因为每次抛出异常时，Throwable 构造函数会自动调用 fillInStackTrace()，它要遍历当前线程所有栈帧、生成字符串、填充 StackTraceElement[] 数组——这个过程不依赖 GC，但耗 CPU、占内存、破坏 CPU 缓存局部性。实测一次 new RuntimeException() 可能比空方法慢 100 倍，常见耗时在 1–10ms 量级。
- 栈越深，开销越大：调用链 20 层 vs 5 层，耗时可能翻倍
- 高频场景下（如解析循环、状态机跳转），它会成为 CPU 火焰图里最亮的那条线
-
e.printStackTrace()不是罪魁，但会触发完整堆栈格式化，放大问题
哪些场景真需要关掉 fillInStackTrace
不是所有异常都值得优化，只针对「高频、可预期、无需调试上下文」的错误类型。比如 HTTP 客户端收到 404、配置项缺失默认值、缓存未命中等——它们本质是业务流程分支，不是程序崩溃。
- 自定义异常类中重写
fillInStackTrace()返回this，彻底跳过栈收集 - JDK 8+ 可用构造函数参数关闭：
new RuntimeException("", null, false, false) - 避免在日志中无条件调用
e.getStackTrace()或e.printStackTrace() - 慎用于开发/测试环境——关掉后堆栈为空，排查会变困难
try-catch 本身不慢，但你可能误用了它
字节码层面，try-catch 只往方法异常表里加几条记录，JIT 在没抛异常时完全内联，零成本。真正的代价永远来自「抛」，不是「抓」。
- ❌ 把
Integer.parseInt(str)放 try 里判断是否为数字——这是典型反模式 - ✅ 改用
Ints.tryParse(str)（Guava）或正则预检：str.matches("-?\d+") - ❌ 数据库查不到就靠
NoResultException走 catch 分支 - ✅ 用
if (rs.next())或返回Optional<t></t>
虚拟线程 + 异常 = 更难发现的性能陷阱
虚拟线程生命周期极短，一个 fillInStackTrace() 调用可能吃掉整个任务 30% 的执行时间，而火焰图里它常被淹没在 carrier 线程的调度开销里，难以定位。
- 用
Thread.ofVirtual().uncaughtExceptionHandler统一捕获，避免异常静默丢失 - 压力测试时开启 JVM 参数
-XX:+PrintGCDetails -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，观察是否频繁内联失败 - 结构化并发中，别在
StructuredTaskScope外层 try 包裹全部 fork，应下沉到每个任务内部做轻量预检
真正难处理的，从来不是“要不要关 fillInStackTrace”，而是怎么把「本不该算异常」的逻辑，从异常路径里彻底摘出来。
