Java中异常性能开销主要来自throw时的栈追踪生成，而非try-catch语句本身；应避免用异常做流程控制，优先采用预检查、Optional或结果封装等低开销替代方案。
Java中抛出并捕获异常确实有显著性能开销，但仅在异常实际被抛出时才发生；try-catch语句块本身（无异常发生）几乎不带来运行时成本。
异常创建和栈追踪是主要开销来源
每次调用 new Exception() 或 throw new RuntimeException()，JVM 必须：
- 生成完整的栈帧快照（即填充
StackTraceElement[]），这个过程涉及遍历当前线程所有栈帧，耗时与调用深度正相关 - 触发对象分配和可能的 GC 压力，尤其在高频异常场景下（如循环内误用异常控制流程）
- 若异常未被捕获，还会额外触发未捕获异常处理器逻辑
实测表明：构造一个带完整栈追踪的 Exception 比构造普通对象慢 10–100 倍；而 RuntimeException 子类（如 IllegalArgumentException）开销略低，但差异不大。
不要用异常做流程控制
这是最常被踩的坑。例如用 NumberFormatException 判断字符串是否为数字，或用 NoSuchElementException 替代 Iterator.hasNext()：
立即学习“Java免费学习笔记（深入）”；
for (String s : list) {
try {
int n = Integer.parseInt(s); // 错误：把解析失败当作“正常分支”
process(n);
} catch (NumberFormatException e) {
continue;
}
}
正确做法是预检查或使用更轻量 API：
- 用
Character.isDigit()或正则预筛，或改用Integer.tryParseInt(String)（Java 17+） - 用
Optional.ofNullable(...).map(...).orElse(...)替代空指针异常兜底 - 集合操作优先调用
containsKey()、getOrDefault()而非依赖NullPointerException
try-catch 的编译与 JIT 行为
try-catch 本身不降低热点代码性能，但会影响 JVM 优化：
- 包含
catch块的方法，JIT 编译器可能禁用某些激进优化（如栈替换、部分内联），尤其当异常处理路径复杂时 - 频繁抛异常会污染分支预测，导致 CPU 流水线频繁冲刷
- 如果异常类型太宽泛（如
catch (Exception e)），JVM 难以做类型特化，间接影响性能
建议：只捕获明确需要处理的异常类型，避免 catch (Throwable)；对已知不会抛异常的代码段（如纯数学计算），不必包裹 try-catch。
替代方案与低开销实践
当错误情况可预期且高频，优先选返回值而非异常：
- 用
Optional表达可能为空的结果（如Map.get()） - 自定义结果类（如
Result）封装成功/失败状态，避免 JVM 异常机制介入 - 对必须抛异常的场景，考虑重用异常实例（仅限不可变、无栈追踪需求的场合，如静态
private static final IllegalArgumentException ILLEGAL_ARG），但需谨慎——多数情况下丢失栈信息得不偿失
真正影响性能的从来不是 try 关键字，而是 throw 那一瞬间的栈展开动作。只要异常不飞起来，代码就还是那个代码。
