java异常会影响性能吗

简短结论：Java 异常本身“会不会影响性能”，取决于你怎么用。
正常业务逻辑不要用异常来控制流程；异常在“发生”时才贵，不抛就不贵。

下面分层说明。

一、异常“不抛”的时候，几乎不影响性能

try {
    // 没有异常发生
} catch (Exception e) {
}

• JVM 只是做了结构上的处理
• 不会创建异常对象
• 性能损耗可以忽略不计

✅ 所以：try-catch 本身不是性能杀手

二、异常“抛出”的时候，性能开销主要来自这几点

1️⃣ 创建异常对象

throw new RuntimeException("error");

会做：

• 分配对象
• 调用构造函数
• 填充堆栈信息（最贵）

fillInStackTrace() 会遍历调用栈

2️⃣ 填充堆栈跟踪（Stack Trace）

这是最耗性能的部分：

e.getStackTrace()

• 异常越深（调用链越长）
• 开销越大

3️⃣ 异常传播

异常从方法一层层往外抛：

• 需要 unwind stack
• 匹配 catch 块
• 比普通 return 慢很多

三、不同异常类型的性能差异

✅ 轻量写法（推荐）

throw new MyBusinessException("msg");

❌ 重量写法

throw new Exception("msg");

更快的方式（极端场景）

public class NoStackException extends RuntimeException {
    @Override
    public synchronized Throwable fillInStackTrace() {
        return this; // 不填充堆栈
    }
}

⚠️ 但可读性 & 调试性会变差

四、最常见的性能误区 ❌

❌ 用异常做流程控制

try {
    Integer.parseInt(str);
} catch (NumberFormatException e) {
    // 正常业务逻辑
}

问题：

• 异常非常慢
• 语义错误
• 难以维护

✅ 正确方式：

if (str == null || !str.matches("\\d+")) {
    // 处理非法输入
}

五、真实场景中的性能影响

正常系统

• 偶尔抛异常（错误、超时）
• 性能影响可以忽略

高并发 / 高频调用

• 每秒几万次异常
• 就会明显影响吞吐

六、什么时候该用异常？

✅ 用异常的场景：

• 真正的“异常”情况
• 程序无法继续
• 错误需要中断流程

❌ 不要用异常：

• 参数校验
• 分支判断
• 正常业务返回

七、总结一句话

Java 异常不是不能用，而是不能“滥用”。
异常在“抛”的时候才贵，尤其是堆栈追踪。

如果你愿意，我可以：

• 给你做异常 vs 返回值的性能对比
• 或针对你具体业务场景给建议