Java 异常处理的真实成本：从栈回溯到字节码

“异常很慢，不要在循环里 try-catch”是常见的性能建议，但它把两件不同的事混在了一起：try-catch 的静态结构，和 throw 发生后的动态过程。前者在正常路径上几乎不产生指令；后者要构造对象、遍历栈帧、填充堆栈，代价可能高出几个数量级。把字节码和 JVM 的处理流程拆开，才能判断什么时候该优化，什么时候只是无谓的焦虑。

一、正常路径：异常表只是元数据

Java 的 try 不会在进入和退出时插入任何指令。编译器把受保护的范围记录在 Code 属性的 exception_table 里，每条记录包含四个字段：起始 pc、结束 pc（不含）、处理器 pc，以及捕获类型的常量池索引。只有执行到 athrow 时，JVM 才会查这张表。看一个最小例子：

public static int div(int a, int b) {
    try {
        return a / b;
    } catch (ArithmeticException e) {
        return -1;
    }
}

javap -c 的输出是：

0: iload_0
1: iload_1
2: idiv
3: ireturn
4: astore_2
5: iconst_m1
6: ireturn
Exception table:
   from    to  target type
       0     4     4   Class java/lang/ArithmeticException

from 0、to 4 表示 pc 0 到 3 受保护，target 4 是处理器入口。正常除法成功时直接 ireturn，不会读取异常表；只有 idiv 因除零抛出异常时，JVM 才跳到 pc 4，把异常对象压栈，再由 astore_2 存入局部变量。catch_type 为 0 表示捕获所有类型，finally、synchronized 的 monitorexit 以及 try-with-resources 的清理逻辑都会生成这种 catch-all 条目。

因此，finally 通常会让异常表多一条记录，try-with-resources 还会生成调用 addSuppressed 的代码；它们增加的是字节码体积和栈映射帧的数量，而不是每次循环的运行时检查。把 try 放在循环里面，并不会因为“进入 try”而变慢。

二、抛出路径：从 athrow 到栈回溯

真正昂贵的是 athrow 之后发生的事。JVM 先弹出栈顶的 Throwable；如果引用为 null，则立刻抛出 NullPointerException。然后它从当前 pc 开始查当前方法的异常表：命中就把操作数栈清空，压入异常对象，跳到处理器；没命中就弹出当前栈帧，回到调用者，从调用点的下一条指令继续查找。finally 之所以能保证执行，是因为它被编译成了 catch-all 处理器；如果所有帧都没有匹配的处理器，线程的 uncaught exception handler 会接手，默认实现打印堆栈。

构造异常对象本身并不慢，new 在 TLAB 里只是指针碰撞；慢的是 Throwable 构造器里的 fillInStackTrace()。它要遍历当前线程的整个调用栈，记录每一帧的类、方法、文件名和行号。JDK 9 之后，backtrace 先以内部格式保存，StackTraceElement[] 在第一次调用 getStackTrace() 时才生成，这减少了一部分开销，但栈遍历仍然发生在抛出时刻。每一次 getStackTrace() 还会克隆数组，频繁调用同样不便宜。

代价随栈深增长。一个在深递归或长调用链里抛出的异常，可能比浅栈异常贵得多。HotSpot 提供 -XX:MaxJavaStackTraceDepth 控制记录的最大帧数（默认 1024），也可以用 Throwable(String, Throwable, boolean, boolean) 构造器的最后一个参数关闭堆栈记录。还有 -XX:-StackTraceInThrowable 可以全局关闭栈回溯，但生产环境很少应该这么做，除非你确定不需要任何异常现场。

另一个容易让人困惑的现象是“日志里突然没有堆栈了”。HotSpot 的 OmitStackTraceInFastThrow 优化会在同一位置反复抛出某几类隐式异常（如 NPE、数组越界、类型转换、除零）后，复用预分配的、没有堆栈的异常实例。这样做是为了降低高频异常的代价，但会让排障信息消失。诊断时可以加 -XX:-OmitStackTraceInFastThrow 复现完整堆栈。

三、JIT 眼中的 try-catch

在 JIT 的眼里，异常处理器是控制流图里的额外边。C2 能内联带处理器的方法，也能把很少走的抛出路径编译成 uncommon trap；第一次真正抛出时可能触发去优化，然后重新编译。异常表本身不会让正常路径多一次分支，但它会给优化增加约束：跨越可能抛异常的调用做代码移动、消除数组边界检查、重排循环里的操作，都必须保持原有的异常语义。所以“try 完全零成本”不准确，更准确的说法是“正常路径没有直接的指令成本，但可能有间接的优化限制”。

用一个常见的反例来说明抛出成本。判断栈是否为空，应该用返回值而不是异常：

Deque<Integer> stack = new ArrayDeque<>();
while (true) {
    Integer x = stack.poll();   // 空时返回 null
    if (x == null) break;
    process(x);
}

如果换成 stack.pop()，空栈时每轮都会抛 NoSuchElementException：构造对象、填充堆栈、展开到处理器，再继续循环。语义上只是“结束循环”，成本却从一次判空变成了一次异常抛出。

解析场景也一样：

try {
    return Integer.parseInt(s);
} catch (NumberFormatException e) {
    return 0;
}

如果绝大多数输入都非法，这段代码就是用异常做正常的控制流。每次失败都要填充一次堆栈，吞吐量会明显下降。可以先用字符检查做快速判断，或者把异常留给真正异常的情况；但也不要用复杂正则替代一个简单的循环判断，优化要看实际数据分布。

四、把成本量化：工具与指标

微基准测试要用 JMH，不要用 System.nanoTime() 手写循环。一个典型的 benchmark 方法如下：

@Benchmark
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public int parseOrZero() {
    try {
        return Integer.parseInt(input);
    } catch (NumberFormatException e) {
        return 0;
    }
}

JMH 会处理预热、多次迭代和死代码消除。就数量级而言，正常返回通常是纳秒级；一次抛出并填充堆栈通常是微秒级甚至更高，具体取决于栈深、异常类型和 JIT 状态。不要拿某一次测试的绝对数字当结论，应该看“异常率 × 单次成本”对吞吐和 GC 的影响。

线上可以用 JFR 的 jdk.JavaExceptionThrow 和 jdk.JavaErrorThrow 事件统计异常抛出次数和类型，也可以结合 async-profiler 查看异常路径的火焰图。-XX:+PrintCompilation 和 -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 能帮助确认某段代码是否被内联、是否因异常边而反复去优化。异常对象和堆栈数组都会占用堆空间，异常率高的服务还应关注分配速率和 GC 日志。

五、实践建议与踩坑

第一，不要用异常表达可预期的业务分支。查找失败返回 null/Optional，循环结束用状态判断，参数校验在入口完成，把异常留给真正异常的情况。第二，捕获具体的异常类型，不要在内层随手 catch (Exception) 或 catch (Throwable)；边界层统一处理时也要保留原始异常。第三，不要吞异常，也不要只记录 e.getMessage()；日志 API 传入异常对象才能打印堆栈，同时避免“记录后又原样抛出”造成重复日志。

第四，包装异常会再填充一次堆栈，深层调用链里成本会叠加；需要补充上下文时保留 cause，不要在循环里反复包装。第五，finally 里的 return 会吞掉正在传播的异常，这是语义错误而不只是性能问题；finally 里也不要抛出新异常覆盖原异常。第六，try-with-resources 的 close() 抛出的异常会作为 suppressed 附加到主异常上，资源实现应保证 close() 幂等且尽量不抛异常。

第七，对于确实高频、且用于控制流的异常，可以用关闭堆栈记录的构造器降低开销，但不要池化或跨线程复用 Throwable，它的状态和堆栈都不是为共享设计的。第八，热点路径优先用判空、isEmpty()、边界检查替代捕获 NPE、NoSuchElementException、IndexOutOfBoundsException，但不要为了“零异常”把代码改成难以阅读的状态机。最后，异常消息可能带出 SQL、文件路径、内部地址或令牌，在 API 边界要脱敏；对外返回统一错误码，把详细堆栈留在服务端日志里。