Java异常性能影响主要在throw而非catch，因栈跟踪生成等开销使抛出比普通调用慢10–100倍；应避免用异常控制业务流程，对可预期条件优先使用显式判断。
Java中异常确实会影响性能，但影响程度取决于使用方式——抛出并捕获异常本身开销较大，而仅声明或捕获已发生的异常（不主动抛出）开销极小。关键不在“有没有异常”，而在“是否频繁抛出异常”。
异常抛出是性能瓶颈的主因
每次调用 throw 时，JVM 需要：
- 生成完整的堆栈跟踪（
StackTraceElement[]），遍历当前线程所有栈帧 - 填充异常对象的字段（如 cause、message、suppressed 异常等）
- 触发可能的异常处理器查找与分派逻辑
这个过程比普通方法调用慢10–100倍（实测常见于 50–200ms/次量级，取决于栈深度）。例如，在循环中用 Integer.parseInt() + catch (NumberFormatException) 做输入校验，远不如先用正则或 Character.isDigit() 预判断高效。
异常捕获本身开销可忽略
单纯写 try-catch 块（未发生异常）几乎零成本：现代 JVM（HotSpot）在无异常路径下会将 try-block 编译为常规指令，不插入额外检查。只有当异常真实抛出时，才触发昂贵的栈展开（stack unwinding）和异常处理逻辑。
立即学习“Java免费学习笔记（深入）”；
因此，把 try-catch 放在合理位置（如方法入口、IO边界）不会拖慢正常流程。
避免用异常控制业务流程
这是最常被误用的场景。典型反例包括：
- 用
Optional.get()+NoSuchElementException替代isPresent()判断 - 用
Map.get(key)返回null后直接调用方法，再靠NullPointerException捕获做分支 - 解析配置时依赖
IOException区分“文件不存在”和“文件损坏”
这些本可用布尔判断、返回值或状态码清晰表达的逻辑，一旦交给异常处理，就引入了非必要开销和可读性下降。
优化建议：该用就用，不该抛别抛
异常机制设计初衷就是处理“异常情况”，不是替代 if-else。实践中可遵循：
- 对真正意外、不可预测、无法提前验证的错误（如网络中断、磁盘满、权限拒绝），放心用异常
- 对可预期、可检测的条件（如用户输入格式、参数范围、键是否存在），优先用显式判断
- 必要时自定义异常并重写
fillInStackTrace()（返回this）来跳过堆栈收集（慎用，会丢失调试信息） - 日志记录异常时，避免在
catch块里重复打印堆栈（如 SLF4J 的logger.error("msg", e)已包含，不用再e.printStackTrace()）
不复杂但容易忽略：性能问题往往不出现在 catch，而出现在 throw。
