Java异常机制的性能损耗核心在于throw操作而非try-catch语法，因fillInStackTrace()触发栈遍历和对象构造；异常表为静态元数据，无异常时零开销。
Java异常机制对标准业务控制流的性能损耗，核心不在try-catch语法本身，而在于把throw当作“分支跳转”来用——这会触发昂贵的栈遍历和对象构造，严重偏离JVM的设计预期。
异常表不拖慢正常执行，但throw是重量级操作
编译后，每个try-catch块都会生成一张异常表（Exception Table），它只是字节码里的静态元数据。JVM在无异常时完全忽略它，JIT还会将try块内联，零额外开销。真正耗时的是throw那一刻：
- JVM必须调用
fillInStackTrace()，暂停线程、遍历全部栈帧 - StackTraceElement，拼装成字符串数组
- new RuntimeException()耗时1–10ms，比空方法调用慢50–200倍
用异常控流程 = 把可预判逻辑交给高成本路径
当“用户名已存在”“库存不足”“参数格式错误”这类业务规则，本可通过if、正则、Optional或状态枚举直接判断，却选择靠catch IllegalArgumentException捕获来推进流程，就等于主动绕开CPU缓存与JIT优化，钻进最慢的代码路径：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
Integer.parseInt(str)后捕获NumberFormatException→ 改用Ints.tryParse(str)或str.chars().allMatch(Character::isDigit) -
map.get(key).toString()不判空 → 改用map.getOrDefault(key, "default")或Optional.ofNullable(map.get(key)) -
repository.findById(id).get()→ 改用repository.findById(id).orElse(null)或封装Result<User, String>
替代方案更轻、更清晰、更可控
业务分支的本质是状态决策，不是程序崩溃。用专为该场景设计的结构，性能和可维护性都更好：
立即学习“Java免费学习笔记（深入）”；
-
Optional：表达“可能存在”的语义，
isPresent()、orElse()全是普通方法调用，无栈开销 -
状态枚举：如
OrderStatus.PAID、OrderStatus.OUT_OF_STOCK，switch匹配快且类型安全 -
结果封装类：如
Result<T, E>，含isSuccess()、getError()等轻量方法，支持携带上下文数据 -
预检+断言工具：如
Objects.requireNonNull()（不抛异常）或Preconditions.checkArgument()（仅校验失败时抛）
真要抛异常时，别让开销雪上加霜
网络超时、磁盘IO失败等不可预测错误，仍需异常。此时可小幅减负，但不能牺牲可调试性：
- JDK 8+ 可关闭堆栈：
new RuntimeException("", null, false, false) - fillInStackTrace()返回
this（仅限内部高频、无需诊断的场景） - logger.error("msg", e)，避免重复调用
e.printStackTrace() - String msg = "timeout for " + key;，再
throw new TimeoutException(msg)
