try块本身不降低正常执行性能，因异常表仅在抛异常时查表；finally导致字节码膨胀并阻碍jit内联；空catch阻止栈轨迹剪枝；try边界会抑制jit循环优化。
try块会让JVM生成额外的异常表条目
Java编译器不会把 try 块编译成“执行时加锁”或“插入检查指令”，而是往class文件里写一张异常表（Exception table），记录每个 try 范围的起止字节码偏移、对应 catch 的起始位置，以及捕获的异常类型。这张表在类加载时被JVM读入，但**不参与日常指令流水线调度**——它只在真正抛出异常时才被查表跳转用。
常见错误现象：javap -v 看到大量重复的 exception table 条目，误以为“每个try都拖慢正常路径”。其实只要没异常，JVM连这张表都不看一眼。
- 使用场景：方法里有多个
try-catch套嵌或并列，异常表会变长，但仅影响类加载阶段内存占用，不影响运行时性能 - 参数差异：
catch (Exception e)和catch (IOException e)在异常表里是不同条目，前者可能覆盖更多子类，查表时匹配更慢（微秒级） - 性能影响：异常表本身不触发分支预测失败，也不导致CPU流水线清空；真正代价在
throw那一刻——要填充栈轨迹、遍历异常表、跳转到handler
finally块强制插入goto和dup指令，影响热点代码内联
哪怕 finally 里只有一行 return，javac也会把它“复制”到每个 try 正常退出点、每个 catch 退出点，再加一个异常出口。这导致字节码膨胀，且插入大量 goto 和 dup 指令。
常见错误现象：用JITWatch或 -XX:+PrintCompilation 发现含 finally 的方法迟迟不被C2编译，或者编译后生成的汇编里出现意外的跳转逻辑。
立即学习“Java免费学习笔记（深入）”；
- 使用场景：资源关闭（如
InputStream.close()）必须放finally，但若该方法本身是高频调用的工具方法，就可能卡住JIT内联决策 - 性能影响：C2编译器对方法大小敏感；一旦字节码超阈值（默认约100字节），就降级为C1编译，甚至不编译；
finally是常见超限原因 - 替代方案：优先用
try-with-resources——它由编译器展开为等效字节码，但语义更清晰，JIT也更容易识别可优化模式
空catch块让JVM无法做栈轨迹剪枝
写 catch (Exception e) { } 看似省事，实际等于告诉JVM：“我可能需要这个异常对象的完整栈信息”。JVM因此不会在抛出时跳过填充栈帧，哪怕你根本没用 e.getStackTrace()。
常见错误现象：压测时发现 throw 操作耗时突增，尤其在高并发下，Throwable.fillInStackTrace() 成为热点方法。
- 使用场景：网络调用超时、文件不存在等预期异常，本可直接忽略或转为返回值，却用了空catch
- 为什么这样做：JVM无法静态判断你是否后续会用到栈轨迹，只要存在
catch变量绑定，就默认保留全量信息 - 实操建议：真要忽略，用
catch (Exception e) { /* ignore */ }不够，得改成catch (Exception ignored) { }并确保变量名是ignored或ex等常见忽略名——部分JVM版本（如ZGC启用时）会据此做轻量剪枝 - 更彻底方案：用
throw new RuntimeException("message", null)显式传null，跳过fillInStackTrace
try块边界影响JIT的循环优化和寄存器分配
JIT编译器在做循环优化（如循环展开、向量化）前，会检查循环体内是否包含异常出口。只要任意一条字节码可能抛异常（比如数组访问、类型转换），整个循环就大概率被标记为“有异常风险”，从而禁用某些激进优化。
常见错误现象：一段纯计算循环，只因开头加了个 try，生成的汇编里多出一堆保护性检查和冗余寄存器保存/恢复。
- 使用场景：数值计算、图像处理等紧循环中混入了I/O或配置读取逻辑，被迫用try包裹
- 解决思路：把可能抛异常的操作拆到循环外；或用防御式编程（如先
if (arr != null && i ）替代 <code>try-catch - 兼容性注意：GraalVM EE 的AOT编译对异常控制流更敏感，同样代码在HotSpot跑得稳，在Graal里可能直接退化为解释执行
异常处理真正的性能成本不在 try 关键字本身，而在 throw 触发那一刻的上下文快照、表查找、栈展开——这些动作无法被CPU流水线隐藏。写代码时盯着 try 块数量没意义，盯住哪几行真正会 throw、谁在接住、接住后干了什么，才踩得到点上。
