Java中异常仅在抛出时显著影响性能：栈轨迹生成、内存分配和JIT优化受阻；try-catch本身无异常时几乎零开销；禁用异常做控制流，优先预检或使用Optional等语义更优的替代方案。
Java中抛出和捕获异常确实显著影响性能，但仅在异常实际发生时；try-catch语句块本身（无异常抛出）几乎不带来运行时开销。
异常抛出时的性能开销在哪
每次调用 throw 会触发完整栈轨迹（stack trace）生成：JVM需遍历当前线程栈帧，填充 StackTraceElement[]，这涉及大量对象分配与字符串操作。即使你重写了 Throwable.fillInStackTrace() 为空实现，部分JVM（如HotSpot）仍可能在首次访问栈信息时延迟构造。
- 典型耗时：在现代JVM上，一次
throw可能比普通方法调用慢100–1000倍 - 堆内存压力：每个异常实例都携带栈数组，频繁抛出会加剧GC压力
- JIT优化受阻：异常路径属于“罕见分支”，JVM通常不会对
catch块做深度优化
try-catch 本身是否拖慢正常流程
只要没发生异常，try-catch 对热点代码性能几乎无影响。JVM在类加载阶段就将异常表（exception table）写入字节码，运行时仅靠指针查表判断是否匹配，不插入额外指令或检查。
- 不增加方法内联难度（HotSpot可正常内联含
try-catch的小方法） - 无异常时，
try块内变量读写、循环、分支行为与无try完全一致 - 但若
catch块过大或含复杂逻辑，可能间接影响方法总大小，从而降低JIT编译阈值触发概率
哪些场景最容易误用异常做控制流
用异常替代常规条件判断是性能杀手，尤其在高频路径中。典型反模式包括：
立即学习“Java免费学习笔记（深入）”；
- 用
NumberFormatException判断字符串是否为数字（应先用String.chars().allMatch(Character::isDigit)或正则预检） - 用
Optional.get()+NoSuchElementException替代isPresent()检查 - 在循环内反复
parseDouble并吞掉异常来“过滤”非法输入 - 自定义业务异常（如
UserNotFoundException）在ID查询中作为“未找到”的主逻辑返回方式
这些写法会让本该 O(1) 的判断退化为 O(N) 的异常构造+GC，且掩盖真实错误信号。
如何安全地平衡可读性与性能
关键不是避免 try-catch，而是避免在预期会发生的情况中抛异常。例如：
- IO操作必须用
try-catch，因为IOException是真实外部不确定性，无法预判 - 解析用户输入前，可用轻量预检（如
StringUtils.isNumeric()）筛掉明显非法值，再进try-catch处理边界 case - 对已知格式的内部数据（如配置项），用断言或构建时校验，而非运行时抛异常
- 必要时使用
Throwable(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace)构造器禁用栈追踪（仅限极低层、高频、可控场景）
真正难处理的是那些既需要语义清晰又高频发生的“半异常”情况——比如 Map 查键，get() 返回 null 不够明确，但为每个 miss 都抛 KeyMissingException 又太重。这时候，往往得回归设计：用 Optional 或专用结果类型，而不是迁就异常机制。
