抛出自定义异常性能损耗核心在throw时fillinstacktrace()栈遍历，耗时1–5μs，比if判断慢100–500倍；优化方式为重写该方法返回this或设writablestacktrace=false，仅适用于无需诊断的业务异常。
抛出自定义异常在 JVM 中的性能损耗，核心不在 catch，而在 throw 的那一刻——JVM 必须构建完整栈轨迹（stack trace），这个动作本身开销显著，且无法被 JIT 优化绕过。
自定义异常的默认开销来源
Java 中所有继承自 Throwable 的异常，默认构造器都会调用 fillInStackTrace()。该方法会遍历当前线程整个调用栈，采集每一帧的方法名、类名、行号等信息，生成一个深度绑定上下文的 StackTraceElement[] 数组。栈越深、方法嵌套越多，耗时越长。
- 一次
throw new MyException("msg")在 HotSpot 17 下平均耗时约 1–5 μs（实测值，非理论估算） - 同等逻辑若改用
if (invalid) return Result.error("msg")，耗时通常低于 10 ns —— 差距达 100–500 倍 - 即使你立即
catch并吞掉它，throw 已完成，开销已发生
哪些自定义异常更慢？
不是所有自定义异常都一样慢。以下三类在压测中暴露明显瓶颈：
-
未重写 fillInStackTrace() 的异常：比如仅继承
RuntimeException但没覆盖该方法，完全走默认路径 - 在高频路径（如网络解析循环、DTO 转换、JSON 反序列化）中 throw：每秒数千次 throw，μs 累积成 ms 级延迟
- 异常对象被频繁创建且不复用：每次 throw 都 new 一个新实例，触发额外 GC 压力（尤其在新生代 Eden 区）
如何做真实有效的 benchmark？
用普通 for 循环 + System.nanoTime() 测异常开销是无效的——JIT 会内联、逃逸分析甚至消除无用 throw。必须用 JMH（Java Microbenchmark Harness）控制变量：
- 加
@Fork(1)和@Warmup(iterations=3)避免预热干扰 - 用
Blackhole.consume()防止 JIT 优化掉异常抛出行为 - 对比组要严格对齐：同一逻辑下，
throw MyExceptionvsreturn Optional.empty()vsif-return - 注意测量单位：JMH 默认输出纳秒级，但异常实际在微秒量级，建议设
@OutputTimeUnit(TimeUnit.MICROSECONDS)
压测中可落地的优化手段
不是否定异常机制，而是把异常用在它该在的地方——表示真正意外、不可恢复的状况。对可预期的业务错误，换路径：
- 协议解析失败、参数校验不通过等，改用
Result<t string></t>或Optional封装结果 - 必须用异常且确定不需要栈信息（如 RPC 协议层解码失败），重写
fillInStackTrace()并直接return this - 避免在
toString()、equals()、hashCode()这类被容器/框架高频调用的方法里 throw 异常 - 压测时开启
-XX:+PrintGCDetails -Xlog:gc*:uptime,tags，观察异常密集抛出是否引发 Young GC 频率上升（间接证据）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
