异常对性能影响大吗

结论先行：异常本身对性能影响通常不大，但“滥用异常”或“频繁抛异常”代价很高。

下面分层说明，方便你判断是否该担心。

一、异常为什么会有性能开销

异常不是“免费”的，主要成本来自：

1. 异常对象的创建

   • 需要 new Exception()
   • 需要 填充堆栈跟踪（stack trace）
     • 这是最贵的一步
     • 要遍历当前调用栈

2. 控制流跳转

   • 异常是非局部跳转
   • JVM / 运行时需要查找 catch、展开栈

3. JVM 优化受限

   • 频繁抛异常会干扰 JIT 优化
   • HotSpot 会认为这是“罕见路径”

二、不同场景的性能影响

✅ 1. 正常异常（偶尔发生）

影响：几乎可以忽略

try {
    Integer.parseInt("abc");
} catch (NumberFormatException e) {
    // 处理
}

• 一年发生几次：没问题
• 程序启动、初始化失败：完全合理

✅ 这是异常的正确用法

❌ 2. 用异常做“正常流程控制”

影响：非常大

try {
    while (true) {
        readNext(); // 没数据就抛异常
    }
} catch (EndException e) {
    ...
}

问题：

• 每次抛异常 = 创建对象 + 填充栈
• 比 if 慢 几倍到几十倍

❌ 这是反模式

⚠️ 3. 高频调用中抛异常

例如：

• 每秒几万次
• 循环内部
• 网络 / 解析 / 校验逻辑

性能会明显下降

三、一个直观对比（经验值）

注意：具体数字依赖 JVM、栈深度、是否开启 -XX:-OmitStackTraceInFastThrow

四、常见误区

❌ 误区 1：try-catch 本身慢

✅ 错误

try {
    a++;
} catch (Exception e) {}

• 不抛异常时，几乎没影响
• JVM 对 try 块优化很好

❌ 误区 2：异常一定比返回错误码慢

✅ 不一定

• 错误少：异常更清晰
• 错误多：返回状态 / Optional / 错误对象更好

五、什么时候该用异常

✅ 该用异常

• 真正的“异常情况”
• 程序无法继续
• 初始化失败、资源缺失、非法状态

❌ 不该用异常

• 正常的业务分支
• 循环终止条件
• 高频校验失败
• 替代 if / return / Optional

六、替代方案（更快）

✅ 返回状态

if (!isValid(x)) {
    return false;
}

✅ Optional

Optional<User> findUser(int id)

✅ 错误对象

Result<T, Error> execute()

七、一句话总结

异常不是慢，是“被频繁使用时慢”。

如果你愿意，可以告诉我：

• 用什么语言（Java / C++ / Python / Go）
• 使用场景（高频 / 低频 / 是否循环内）

我可以给你更精确的评估或优化建议。