异常表跳转指令性能开销极低，仅在抛出异常时触发查找，正常执行完全绕过；真正昂贵的是athrow引发的完整异常流程。

异常表跳转指令（Exception Table Dispatch）在字节码执行层面的性能开销通常极低，但并非为零——它的实际影响取决于JVM实现、异常是否真实发生、以及异常表的结构复杂度。

异常表本身不触发开销，仅在抛出异常时生效

Java字节码中的异常表（Exception Table）是静态元数据，存储在方法的Code属性中。它只在真正抛出异常且需要查找匹配处理块（catch block）时才被查表使用。正常执行路径完全绕过异常表，不产生任何额外分支或内存访问。

• 无异常时：JIT编译后，异常表对热代码零干扰；解释执行下也无需遍历该表
• 有异常时：需线性或二分查找异常表项（取决于JVM版本与表大小），定位对应handler PC

开销主要来自异常抛出动作，而非跳转指令本身

真正昂贵的是athrow指令触发的完整异常流程：创建异常对象、填充栈轨迹（stack trace）、回溯方法调用链、查找并跳转到handler。异常表查找只是其中一环，耗时占比很小（通常

• 栈轨迹生成（fillInStackTrace）是最大开销源，可占整个athrow耗时90%以上
• 关闭栈轨迹（如继承RuntimeException并重写fillInStackTrace为空）可显著提速
• 异常表若含大量嵌套try-catch或跨方法范围，可能略微增加查找延迟，但现代HotSpot已优化为O(log n)

微基准测试需避开常见陷阱

直接用JMH测“异常表跳转”容易失真，因为测量结果实质反映的是异常创建与抛出的总成本。要隔离跳转环节，需控制变量：

• 复用同一异常实例（避免重复构造和栈填充）
• 使用-XX:-StackTraceInThrowable禁用栈轨迹（JDK 8u60+）
• 确保异常表结构简单（单条entry），排除查找逻辑干扰
• 对比相同代码中athrow vs goto跳转，差值近似为纯跳转开销（通常在纳秒级）

结论：不必为异常表结构过度优化

除非在超低延迟场景（如金融交易核心循环）中每纳秒必争，否则异常表的跳转开销可忽略。更值得投入的是减少异常使用频次、避免在热路径上抛异常、以及精简异常对象生命周期。JVM早已将异常表访问内联、缓存和预判，其效率远高于开发者直觉。