Java中try-catch在无异常时性能开销可忽略，真正性能瓶颈是异常抛出：需栈遍历、trace填充、对象创建与栈展开，耗时可达普通调用百倍以上；应避免以异常作控制流，仅用于处理罕见意外故障。
Java中try-catch本身在无异常时几乎不耗性能，真正拖慢程序的是异常被抛出的那一刻。
正常执行路径下，try-catch开销可忽略
现代JVM（如HotSpot）将try块编译为字节码中的异常表（exception table），不插入额外判断或跳转指令。只要没抛异常，CPU不会多做任何事——就像给一段路标好“此处可能塌方”，但路没塌，车照常开。
- 循环内写 try { ... } catch (Exception e) { }，100万次迭代与不加try耗时差异通常在毫秒级以内（实测约+0.1ms）
- 编译器可能把确定不抛异常的代码从try块中优化移出，进一步降低影响
- JIT编译后，纯try-catch结构对热点代码的吞吐量基本无感知
异常抛出才是性能断崖点
一旦throw发生，JVM必须同步完成多项高成本操作：遍历栈帧填充完整stack trace、查找匹配的catch位置、创建并初始化异常对象、触发栈展开（stack unwinding）。这个过程不是线性增长，而是随调用深度陡增。
- 单次异常抛出耗时通常是普通方法调用的百倍以上（实测10万次异常抛出比10万次除法慢400倍）
- 频繁在循环中因格式错误、空指针、解析失败等抛异常，会导致CPU大量时间花在堆栈处理而非业务逻辑上
- 反复抛同一类异常还会干扰JIT的内联与逃逸分析，使后续优化降级
哪些场景容易踩坑？
问题不在语法，而在语义误用——把异常当控制流用，本质是设计偏差。
立即学习“Java免费学习笔记（深入）”；
- 用parseInt + catch NumberFormatException校验数字 → 改用 Character.isDigit() 或正则预筛
- 逐行parse JSON/时间字符串都套try-catch → 先用轻量正则粗判格式，再集中解析合格项
- HTTP调用失败就捕获Exception再重试 → 明确检查响应码（429/503）、超时异常类型，非错误不走catch
- 数据库查不到就靠EmptyResultDataAccessException控制分支 → 改用count或exists先探查，避免异常驱动流程
什么情况下可以放心用？
异常本意是处理**意外、罕见、无法前置预测**的故障。这类使用既合理又高效。
- 批量读文件时，个别文件被外部进程删除或权限突变
- 调用第三方SDK，文档注明“仅在网络分区或服务宕机时抛IOException”
- 磁盘写入时突然触发OS级I/O错误（如no space left）
- 这些情况发生概率低，且无法通过if提前规避，用try-catch语义清晰、开销可控
