Java中异常捕获本身几乎不消耗性能，真正影响性能的是异常被抛出并创建堆栈信息的过程；只要未发生异常，try-catch开销可忽略，而抛出异常耗时可达普通方法调用的百倍以上。
Java中异常捕获本身（try-catch块的声明）几乎不消耗性能，真正影响性能的是**异常被抛出并创建堆栈信息的过程**。只要没发生异常，try-catch结构对运行时开销可忽略不计。
异常抛出才是性能瓶颈
每次调用 throw new XxxException() 时，JVM会：
- 生成完整的异常堆栈跟踪（
fillInStackTrace()），遍历当前线程所有栈帧 - 分配异常对象内存，并填充类名、消息、堆栈数组等字段
- 若异常未被捕获，还会触发栈展开（stack unwinding），逐层查找匹配的
catch
实测表明：抛出一次异常的耗时通常是普通方法调用的百倍以上，尤其在高频路径（如循环、IO处理、解析逻辑）中滥用异常，会显著拖慢吞吐量。
避免用异常做流程控制
这是最常见的性能反模式。例如：
立即学习“Java免费学习笔记（深入）”；
- 用
NumberFormatException判断字符串是否为数字（应改用String.matches("\\d+")或Integer.parseInt()前预校验） - 用
NullPointerException检查对象是否为空（应直接用obj == null） - 用
NoSuchElementException判断集合是否包含元素（应先调用contains()）
这类写法看似简洁，但把“预期分支”交由异常机制处理，违背了异常设计初衷，也放大了性能代价。
优化异常使用的实用方式
能不抛就不抛：对可预见的错误条件，优先用返回值、Optional、状态码等方式表达；
减少堆栈采集开销：若异常仅用于内部流程跳转且无需调试信息，可继承自 RuntimeException 并重写 fillInStackTrace() 返回 this（慎用，会丢失调试线索）；
复用已知异常实例：对无状态的业务异常（如 InvalidRequestException），可预先创建单例，避免重复构造；
日志记录要克制：避免在 catch 中频繁打印完整堆栈（尤其在循环里），必要时只打关键字段或采样输出。
编译器与JIT对try-catch的优化
现代JVM（HotSpot）对空 try-catch 或仅含简单语句的块做了深度优化：
- 未触发异常时，
try块内代码可被正常内联、去虚拟化、逃逸分析 - JIT编译后，异常处理表（exception table）只影响类加载和首次执行，不影响热点代码执行路径
- 但一旦异常实际发生，就会退出优化代码路径，进入解释执行或重新编译的降级流程
因此，“加了try-catch就变慢”是误解；真正该警惕的是“频繁抛异常”。
基本上就这些。异常是强大工具，不是控制流替代品。用对地方，它既清晰又高效。
