应放心使用 try-catch，但严禁用异常控制流程；其本身无性能开销，真正代价在于 throw 操作的堆分配、栈遍历与展开，需通过前置检查、具体捕获、单条隔离等方式规避可预期异常。

不需要刻意避免 try-catch 本身，但必须严格避免在高性能场景中频繁抛出异常。

try-catch 包裹本身几乎没有开销

现代 JVM（如 HotSpot）对正常执行路径做了深度优化：只要不抛异常，try-catch 块只是字节码里的一段异常表记录，运行时完全不参与控制流判断。JIT 编译器还会把热路径中“从不触发”的异常处理逻辑彻底优化掉。实测表明，在循环内或方法入口加一层空 try-catch，和不加相比，吞吐量差异通常在 ±2% 以内，属于噪声范围。

真正拖慢性能的是 throw new Exception()

每次抛异常都会触发三件高成本操作：

• 分配异常对象（含堆内存申请与 GC 压力）
• 调用 fillInStackTrace() —— 遍历当前线程完整调用栈，提取每帧的类名、方法名、行号，生成数组
• 栈展开（stack unwinding）—— 逐层退出方法，查找匹配的 catch 块

举个例子：一个 20 层深的调用链抛一次 RuntimeException，耗时通常是普通对象创建的 10–50 倍。如果每毫秒都抛一次，CPU 很快就会卡在栈遍历上。

高性能场景下的关键避坑点

不是“少用 try-catch”，而是“别把异常当流程分支”：

• 禁止用异常做条件判断：比如用 Integer.parseInt() + catch NumberFormatException 来校验字符串是否为数字——应改用 StringUtils.isNumeric() 或正则预判
• IO 或网络调用要前置检查：文件存在再读，连接可用再发请求，避免因可预期失败而触发异常
• 批量处理时隔离单条失败：比如解析 1000 条日志，宁可在循环内 try-catch 单条（不抛异常时无负担），也不要让一条错误导致整批中断
• 捕获具体异常类型：用 catch (IOException e) 替代 catch (Exception e)，减少类型匹配开销，也提升语义清晰度

该用还是不该用？看两个信号

放心用 try-catch 的情况：

• 包裹的是真实可能出错的外部依赖（数据库查询、HTTP 调用、文件读写）
• catch 块里只做轻量恢复或日志记录，不嵌套复杂逻辑

需要重构的情况：

• 日志里高频出现同一异常堆栈（说明错误可预测，应转为防御性检查）
• JFR 或 profiler 显示 Throwable.fillInStackTrace 占 CPU 时间 Top 3