try-catch块不抛异常时几乎零开销，因异常处理逻辑静态固化在只读的异常表中，正常执行路径完全绕过；真正开销在于throw触发后线性扫描异常表、构建栈追踪（占70%以上）和栈展开。
try-catch 块本身在**不抛异常时几乎零开销**，这不是靠“优化指令”实现的，而是由 JVM 字节码设计决定的——异常处理逻辑完全静态固化在异常表（Exception Table）中，正常执行路径完全绕过它。
异常表是只读元数据，不参与正常执行
Java 编译器（javac）在生成字节码时，就把每个 try-catch 的边界、捕获类型和 handler 地址写入方法的异常表。这张表独立于指令流，JVM 解释器或 JIT 编译后的机器码在顺序执行时，根本不会读取或检查它，除非真的发生异常。
也就是说：
- 没有额外的条件判断插入到 try 块内部
- 没有隐式分支预测开销
- 没有寄存器保存/恢复用于异常上下文
- CPU 流水线照常运行，无污染
JIT 不“优化”异常表，而是严格保留并精确映射
JIT 编译器不会重写或压缩异常表，它的任务是：把表中记录的字节码偏移量（start_pc / end_pc / handler_pc），准确翻译成对应机器码的地址，并确保运行时异常查找仍能线性匹配。
这个过程带来两个关键事实：
- 异常表结构必须与原始字节码语义一致：哪怕内联后代码布局改变，JIT 也要重建一张逻辑等价的新异常表，否则栈回溯和 catch 匹配会失败
- finally 块不进异常表，但影响内联决策：finally 是通过编译期代码复制实现的（插到每个出口路径），这导致控制流膨胀，让 JIT 更难安全内联含 finally 的方法
真正影响性能的，是异常被抛出那一刻
非异常路径没损耗，但一旦 throw 执行，代价立即显现：
- JVM 线性扫描异常表，查找匹配项（O(n) 时间，n 是表项数）
- 构建完整 stack trace：遍历当前线程所有栈帧，填充每一层方法名、行号、类信息
- 栈帧展开（stack unwinding）：逐层退出，执行每个方法中未完成的 finally
其中，stack trace 构建占总开销 70% 以上，尤其在深调用栈或高频抛出场景（如校验失败循环）下尤为明显。
开发者能做的实际优化
既然异常表本身不可“加速”，优化重点就落在规避异常触发和简化异常路径上：
- 用预检查替代防御性 try-catch：例如用
Objects.requireNonNull(obj)替代try { ... } catch (NullPointerException e) { ... } - 把复杂异常处理逻辑下沉到冷路径方法中，让热路径方法保持“无异常结构”（即不含 try/catch/finally/synchronized 内嵌 try）
- 对固定消息的业务异常，复用静态异常实例，并重写
fillInStackTrace()返回this，跳过栈采集 - 用
-XX:+PrintInlining观察哪些含异常的方法被 JIT 跳过内联，针对性重构
