Java try-catch 真的零开销吗？——字节码异常表揭秘

一句话结论（30s）

try-catch 不是代码分支而是 class 文件末尾的一张异常表，因为正常路径的字节码完全不涉及它、与不带 try-catch 的代码一模一样，所以是真正的零开销。关键设计是”正常零开销、异常才付出代价”：异常时线性扫描异常表，finally 靠编译器复制代码 + any 条目实现；代价是 finally 代码复制带来字节码体积膨胀、异常时 O(条目数) 扫描。

核心原理（2min）

javac 把 try 区间编成异常表记录 from/to/target/type，正常路径直接 load-divide-return；抛异常时 JVM 按当前 pc 顺序线性扫描匹配记录（前闭后开区间 + instanceof）跳转 target，找不到则弹栈在调用者异常表继续查找。finally 靠编译器在所有出口复制 finally 代码并加 type:any 条目保证必执行，try-with-resources 用 addSuppressed 保留主异常不被 close() 异常吞掉。

底层深入（5-10min）

try-catch 不是”代码”，是”表格”

大多数人以为 try-catch 是像 if-else 一样的代码分支，运行时会逐条执行。实际上，JVM 把 try-catch 编译成了 class 文件末尾的一张异常表（Exception Table），正常路径的执行完全不涉及它。

用一个例子来看：

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

javap -c 反编译：

public static int divide(int, int);
  Code:
     0: iload_0
     1: iload_1
     2: idiv              ← 正常路径（除法）
     3: ireturn           ← 正常返回
     4: astore_2          ← catch 块入口（存在局部变量 2）
     5: iconst_m1
     6: ireturn

  Exception table:
     from    to  target  type
       0      3     4   Class java/lang/ArithmeticException

异常表只做一件事：告诉 JVM “第 0 条到第 3 条指令之间，如果抛出 ArithmeticException，跳到第 4 条开始执行”。

💭 思考：异常表为什么记录的是区间（from/to）而不是「每条指令绑定一个 catch」？因为一段 try 块往往几十条指令，用区间可以一次覆盖；真正抛异常时才按 pc 线性扫描去匹配区间，正常路径完全不用碰这张表——这就是零开销的来源。

正常路径：真正的零开销

看上面的字节码：指令 0-3 是 load → load → divide → return，没有任何关于 try-catch 的指令。这 4 条指令就是最简单、最直接的执行路径，完全不经过异常表。这就是”零开销”的含义——正常路径的字节码里完全看不到 try-catch 的痕迹，与不带 try-catch 的代码一模一样。

C++ 的零成本异常（Itanium C++ ABI）虽然也追求正常路径零开销，但需要生成额外的 LSDA（Language-Specific Data Area）和展开表。Java 的异常表更简单——JVM 只在抛出异常时才去查它。

💭 思考：Java 的异常表比 C++ 的 LSDA 简单在哪？因为 Java 是字节码/解释执行，JVM 手里有 pc 和异常类型就能查表；C++ 是本地代码，需要额外生成 LSDA 和展开表、配合栈展开才能恢复现场。前者「异常才查表」，后者「编译期就要为异常预留结构」。

异常时：线性扫描异常表

只有真正抛出异常时，JVM 才做以下事情：

1. 获取当前 pc（程序计数器）的值
2. 遍历当前方法的 Exception Table
3. 找一条记录满足：from <= pc < to 且 异常类型 instanceof type
4. 找到 → 跳转到 target 执行
5. 找不到 → 弹出当前栈帧，递归在调用者的异常表中查找（异常传播）

注意：是从 from 到 to 的前闭后开区间，且 JVM 遍历异常表是顺序线性扫描——异常表按 catch 块出现的顺序排列，先匹配的先使用。这个顺序在编译时就由 catch 块的书写顺序决定了。

💭 思考：为什么 from 是闭区间、to 是开区间？因为异常发生在某条指令上，from <= pc < to 正好覆盖 try 块的指令范围；这条边界规则也和 catch 块书写顺序一起决定了「先匹配先用」，多个 catch 时顺序就是优先级。

finally 的实现：代码复制

finally 块在字节码层面没有特殊指令，它是靠编译器在所有出口复制 finally 代码实现的：

public static int test(boolean flag) {
    try {
        if (flag) return 1;
        return 0;
    } finally {
        System.out.println("cleanup");
    }
}

javap -c 反编译后可以清楚地看到，System.out.println("cleanup") 的字节码出现了两次：一次在 return 1 之前，一次在 return 0 之前。编译器还在异常表中加了一条 type: any（匹配所有异常），保证即使抛异常，finally 也一定执行。

type: any 在异常表中的含义是：匹配所有类型的异常，执行完 finally 代码后，athrow 将异常原样重新抛出让上层处理。

💭 思考：finally 的 type: any 条目为什么必须存在？因为 finally 要在「任何异常」下都执行，只有 any 能兜住所有类型；它执行完 finally 后还得 athrow 把异常原样抛回上层，否则就吞掉了异常。

try-with-resources 的编译后形态

try (BufferedReader br = new BufferedReader(new FileReader("file.txt"))) {
    return br.readLine();
}

编译器把它展开成类似：

BufferedReader br = new BufferedReader(new FileReader("file.txt"));
Throwable var2 = null;
try {
    return br.readLine();
} catch (Throwable var11) {
    var2 = var11;
    throw var11;
} finally {
    if (br != null) {
        if (var2 != null) {
            try {
                br.close();
            } catch (Throwable var10) {
                var2.addSuppressed(var10);  // ← 关键：Suppressed Exception
            }
        } else {
            br.close();
        }
    }
}

两个关键细节：

addSuppressed：如果 try 块和 close() 都抛异常，close() 的异常被附加为 Suppressed Exception，主异常保持为 try 块的异常——不会因为 close() 抛异常而吞掉原始业务异常
生成嵌套的 try-catch-finally 结构保证了即使 close() 失败、即使主逻辑抛异常，所有情况下的资源都能安全关闭

💭 思考：try-with-resources 为什么要引入 suppressed exception 而不是让 close() 异常覆盖主异常？因为主异常才是业务真正的错误，close() 失败是次要的清理问题；如果让 close() 的异常顶掉主异常，排查时你会被「关闭资源失败」误导，看不到真正的根因。

异常表对性能的潜在影响

虽然正常路径零开销，但异常表有边界情况：

异常表过大：一个方法有大量 catch 块时，抛出异常时线性扫描异常表有 O(n) 开销
JIT 的影响：JIT 编译时会把 try-catch 的代码路径识别为”冷路径”，可能对内联和循环优化产生一定影响（C2 编译器对待 try 块内的代码会保守一些）
异常对象的 fillInStackTrace：创建 Throwable 对象时调用 native fillInStackTrace() 遍历当前调用栈生成 stack trace，这是异常处理开销的最大头——比查异常表大几个数量级

总结

路径	做了什么	开销
正常路径	不查异常表，字节码中无 try-catch 痕迹	零
抛出异常	线性扫描异常表 → 跳转	O(异常表条目数)
finally	编译器在每个出口复制代码 + 异常表 `any` 条目	字节码体积膨胀

Java 的异常表设计是典型的”正常零开销、异常才付出代价”的工程策略——比 C 语言的返回码安全（不会漏处理错误），比 C++ 的实现更简单（不需 LSDA），在安全性和性能之间的平衡做得很好。

章末提问

追问 1：try-catch 为什么是「零开销」？这个零开销具体指什么？

结论先行：指正常路径的字节码里完全没有任何 try-catch 的痕迹，和不加 try-catch 的代码执行完全一致。

因为：javac 把 try 区间编译成 class 文件末尾的异常表记录（from/to/target/type），正常路径直接 load→divide→return，根本不查这张表；只有真正抛出异常时 JVM 才按当前 pc 线性扫描异常表。开销从「每次执行都要付出」变成「仅异常时付出」。

追问 2：finally 在字节码层面是怎么实现的？为什么说它靠「代码复制」？

结论先行：finally 没有专门字节码指令，靠编译器在每个出口（每个 return 和抛异常路径）复制 finally 代码，并在异常表加 type:any 条目兜底。

因为：javac 把 finally 体复制到每个 return 之前，保证正常返回也执行；异常表里加一条匹配所有类型的 any 记录，保证抛异常时也执行，执行完再 athrow 重新抛出。代价是 finally 代码多次复制导致字节码体积膨胀。

追问 3：try-with-resources 的 close() 异常为什么不会吞掉主异常？

结论先行：因为编译器把 close() 包进嵌套 try-catch，close() 若抛异常会通过 addSuppressed 附加为主异常的 suppressed exception，主异常保持不变。

因为：编译器展开后的结构里先捕获主异常存到 var2，finally 里 close() 再失败时调用 var2.addSuppressed(var10)，把关闭异常「挂」在主异常下面。这样既能保证资源关闭，又保留了真正的业务根因，排查时不会只见「关流失败」不见「业务报错」。

Java异常表的零开销机制