创建 Exception 对象开销显著，因需填充堆栈跟踪；实测比普通对象慢10–100倍，栈越深越慢；避免在循环等热点路径中频繁 new Exception。
创建 Exception 对象本身就有明显开销
Java 中每次 new 一个 Exception（包括 RuntimeException），JVM 都要填充堆栈跟踪（fillInStackTrace()），这涉及遍历当前线程所有栈帧，生成字符串、缓存类名方法名行号——不是简单内存分配。实测在热点路径中新建 Exception，比普通对象创建慢 10–100 倍，取决于栈深度。
常见错误现象：for (int i = 0; i —— 看似合理，但循环里反复构造异常，一旦触发就是性能雪崩。
- 高频校验场景（如参数检查、状态判断）别用异常表达业务逻辑，改用
if+ 返回码 /Optional/ 断言式工具类（如Objects.requireNonNull不抛异常，Preconditions.checkNotNull才抛，注意区分） - 真需要抛异常时，优先复用已实例化的静态异常对象（仅限不带上下文信息的场景，如空指针保护），例如：
private static final NullPointerException NPE = new NullPointerException(); - 若必须携带动态信息（如变量值），至少把字符串拼接移到异常构造外，避免无谓重复计算：
String msg = "timeout for " + key; throw new TimeoutException(msg);
try-catch 块本身几乎零开销，但捕获异常是重操作
JVM 对未抛出的 try-catch 块做了高度优化：只要没发生异常，现代 HotSpot 几乎不产生额外指令或寄存器压力。真正昂贵的是异常被抛出并被 catch 的那一刻——要展开栈、定位 handler、重建执行上下文。
使用场景：网络调用、IO、反射等本就可能失败的操作，用 try-catch 是正当且必要的；但用它替代 if (map.containsKey(key)) 或 iterator.hasNext() 就是典型滥用。
立即学习“Java免费学习笔记（深入）”；
- 不要写
try { obj.doSomething(); } catch (NullPointerException e) { /* handle null */ }来代替显式判空 - 避免在循环内
catch可预期的异常（如解析失败），应提前过滤或批量处理，让异常成为“例外”而非“常态” - 多 catch 时，把更具体的异常类型放在前面，避免隐式向上转型开销（虽小，但白花钱）
日志中打印异常堆栈会放大性能问题
很多同学只关注 throw，却忽略 log.error("msg", e) 同样会触发 e.printStackTrace() 级别的栈遍历和字符串化——尤其当异常被多次记录（如框架自动打日志 + 业务又手动打），开销翻倍。
常见错误现象：Dubbo 或 Spring MVC 报错后，控制台刷出两段一模一样的堆栈，实际是框架和你的 @ExceptionHandler 各记了一次。
- 除非调试需要，生产环境日志级别设为
WARN或更高，避免INFO级别输出完整异常 - 用 SLF4J 时，确保 logger 调用是条件化的：
if (log.isErrorEnabled()) { log.error("failed to process {}", id, e); }，防止参数字符串拼接 + 异常序列化双重浪费 - 自定义异常类可重写
getStackTrace()或printStackTrace()，对非关键异常返回空数组或精简栈（需权衡排查成本）
某些异常类型天生更重，选型要注意
不是所有异常都一样贵。Exception 和 RuntimeException 子类之间差异不大，但像 InvocationTargetException（反射）、SQLException（驱动封装）、XMLParseException（DOM 解析）这些，内部往往叠加了额外上下文收集或资源清理逻辑，构造和抛出成本更高。
性能影响：在微服务链路中，一个 FeignException 可能比等价的 IOException 多花 2–3 倍时间，因为它要包装原始异常、提取 HTTP 状态、解析响应体。
- 框架封装的异常（如 Spring 的
HttpMessageNotReadableException）尽量少在业务层直接 new，优先用其提供的静态工厂方法（如有） - 自定义异常继承时，若不需要完整堆栈（如领域校验失败），可覆写
fillInStackTrace()直接 return this，跳过开销最大的环节 - 注意 JDK 版本差异：Java 8 的
Exception构造默认走满栈；Java 9+ 加入了Throwable(String, Throwable, boolean, boolean)构造器，第二个boolean参数可关闭堆栈收集
异常不是语法糖，它是 JVM 级别的控制流中断机制。用对地方是健壮性的保障，用错位置就是性能黑洞——尤其当它混在高频路径、日志密集区或被反复构造时，那些“看起来无害”的 new RuntimeException() 最容易被忽视。
