Java异常会影响性能吗？

Java异常性能影响主要在throw而非catch，因栈跟踪生成等开销使抛出比普通调用慢10–100倍；应避免用异常控制业务流程，对可预期条件优先使用显式判断。

Java中异常确实会影响性能，但影响程度取决于使用方式——抛出并捕获异常本身开销较大，而仅声明或捕获已发生的异常（不主动抛出）开销极小。关键不在“有没有异常”，而在“是否频繁抛出异常”。

异常抛出是性能瓶颈的主因

每次调用 throw 时，JVM 需要：

• 生成完整的堆栈跟踪（StackTraceElement[]），遍历当前线程所有栈帧
• 填充异常对象的字段（如 cause、message、suppressed 异常等）
• 触发可能的异常处理器查找与分派逻辑

这个过程比普通方法调用慢10–100倍（实测常见于 50–200ms/次量级，取决于栈深度）。例如，在循环中用 Integer.parseInt() + catch (NumberFormatException) 做输入校验，远不如先用正则或 Character.isDigit() 预判断高效。

异常捕获本身开销可忽略

单纯写 try-catch 块（未发生异常）几乎零成本：现代 JVM（HotSpot）在无异常路径下会将 try-block 编译为常规指令，不插入额外检查。只有当异常真实抛出时，才触发昂贵的栈展开（stack unwinding）和异常处理逻辑。

因此，把 try-catch 放在合理位置（如方法入口、IO边界）不会拖慢正常流程。

避免用异常控制业务流程

这是最常被误用的场景。典型反例包括：

• 用 Optional.get() + NoSuchElementException 替代 isPresent() 判断
• 用 Map.get(key) 返回 null 后直接调用方法，再靠 NullPointerException 捕获做分支
• 解析配置时依赖 IOException 区分“文件不存在”和“文件损坏”

这些本可用布尔判断、返回值或状态码清晰表达的逻辑，一旦交给异常处理，就引入了非必要开销和可读性下降。

优化建议：该用就用，不该抛别抛

异常机制设计初衷就是处理“异常情况”，不是替代 if-else。实践中可遵循：

• 对真正意外、不可预测、无法提前验证的错误（如网络中断、磁盘满、权限拒绝），放心用异常
• 对可预期、可检测的条件（如用户输入格式、参数范围、键是否存在），优先用显式判断
• 必要时自定义异常并重写 fillInStackTrace()（返回 this）来跳过堆栈收集（慎用，会丢失调试信息）
• 日志记录异常时，避免在 catch 块里重复打印堆栈（如 SLF4J 的 logger.error("msg", e) 已包含，不用再 e.printStackTrace()）

不复杂但容易忽略：性能问题往往不出现在 catch，而出现在 throw。