Java中抛出异常会显著影响性能，主因是JVM需生成完整栈轨迹，即使catch住开销也已发生；三类高开销异常包括常见运行时异常、未重写fillInStackTrace()的自定义异常及循环内频繁throw；应避免热路径触发异常，改用预检、返回值等替代方案。
Java中抛出异常确实会显著影响性能
不是所有异常都一样，throw 一个 Exception 的开销远大于普通方法调用，主因是 JVM 需要生成完整的栈轨迹（stack trace）。哪怕你 catch 住了，只要执行了 throw，这个开销就已发生。JIT 编译器也无法对异常路径做有效优化，因为异常路径本就预期“不常走”。
哪些异常开销特别大？
以下三类异常在构造或抛出时成本最高：
-
NullPointerException、ArrayIndexOutOfBoundsException等运行时异常：虽然常见，但每次throw仍会调用fillInStackTrace() - 自定义异常且未重写
fillInStackTrace()：默认行为会遍历整个调用栈，深度越深，耗时越长 - 在循环内频繁
throw异常（如用异常控制流程）：这是最典型的性能反模式，比如用NumberFormatException来判断字符串是否为数字
如何降低异常带来的性能损耗？
关键不是“少用 try-catch”，而是避免在热路径上触发异常机制：
- 用
Integer.parseInt()前先用String.matches("\\d+")或Character.isDigit()做预检，而不是依赖 catchNumberFormatException - 对可预期的错误状态，改用返回值（如
Optional、Result模式）替代异常 - 若必须自定义异常且确定不需要栈信息（如协议解析失败），可重写
fillInStackTrace()并直接return this - 避免在
toString()、hashCode()、compareTo()等被频繁调用的方法中抛异常
异常性能到底差多少？
简单基准测试（JMH，HotSpot 17）显示：
立即学习“Java免费学习笔记（深入）”；
- 一次
throw new RuntimeException()耗时约 1–5 μs（取决于栈深度） - 同等逻辑用 if-else 分支，耗时通常低于 10 ns —— 差三个数量级
- 在吞吐量敏感场景（如网络包解析、高频交易）中，异常误用可能直接拖垮 QPS
真正容易被忽略的是：异常开销不只在 catch 块里，而是在 throw 那一刻就锁死了性能瓶颈。别等压测报警才去翻 throw 的位置。
