会，核心开销在异常抛出而非try-catch语法本身；throw触发栈展开、StackTrace生成及同步锁竞争，比普通方法调用慢50–200ms，且阻碍JIT内联与优化。
Java中异常处理对JVM执行效率的影响，核心不在写不写try-catch，而在于有没有真正抛出异常。压测中观察到的性能下降，几乎全部来自throw那一刻的开销，而非语法结构本身。
抛出异常才是真正的性能瓶颈
每次throw操作会触发完整栈展开（stack unwinding）和StackTraceElement[]生成，JVM需遍历当前线程所有栈帧、分配数组、填充方法名/行号/类名等信息。实测显示，一次throw比普通方法调用慢50–200ms（取决于栈深度），在高频路径中极易成为压测热点。
- Throwable.fillInStackTrace()是同步操作，高并发下存在锁竞争
- 每个异常对象携带完整栈轨迹，加剧年轻代GC压力
- JIT编译器将异常路径视为“冷分支”，不会对其做深度优化（如循环展开、内联）
- 频繁抛异常会使C2编译器降级为C1，甚至跳过编译，回归解释执行
try-catch块本身几乎零开销
现代HotSpot JVM将try-catch编译为异常表（exception table），仅记录字节码偏移范围与handler位置。该表在类加载时载入内存，运行时无异常发生时完全不参与指令流水线——不插入检查指令、不干扰分支预测、不导致CPU流水线清空。
- javap -v看到的大量exception table条目，只影响类加载内存占用，不影响运行时速度
- 方法内含try-catch但无异常抛出时，变量访问、循环、分支行为与纯代码一致
- 小方法（如≤100字节）即使带try-catch，仍可被JIT正常内联
finally和空catch会悄悄拖慢JIT
finally不是“安全保险”，而是字节码膨胀源：javac会把其中逻辑复制到每个正常退出点、每个catch出口及异常出口，插入goto/dup指令。这直接推高方法字节码体积，易触发JIT内联阈值限制。
立即学习“Java免费学习笔记（深入）”；
- 含finally的方法更难被C2编译，压测中常表现为“迟迟不进入优化态”
- 空catch（如catch (Exception e) { }）阻止JVM做栈轨迹剪枝，强制填充完整StackTrace，哪怕你从不调用e.getStackTrace()
- 推荐用try-with-resources替代手动finally，语义清晰且JIT更易识别优化模式
压测中典型误用与优化方向
压测暴露的性能问题，90%源于把异常当控制流用。这不是“要不要用异常”的问题，而是“是否在可预期场景主动抛异常”的问题。
- 避免在循环内parse数字并吞NumberFormatException → 改用String.chars().allMatch(Character::isDigit)预检
- 避免用Optional.get()触发NoSuchElementException → 先调isPresent()或用orElse()/map()
- 避免自定义业务异常（如UserNotFound）作为查询主返回路径 → 改用Optional
或Result<User> - 对已知格式内部数据（如配置项），改用构建时校验或断言，而非运行时抛异常
