会，但只在 throw 发生时才明显拖慢程序；try-catch 本身几乎不耗性能。throw 慢因需遍历调用栈、生成 StackTraceElement 并拼装字符串数组，耗时 1–10ms；catch 无成本，JIT 会内联 try 区域。
会，但只在 throw 发生时才明显拖慢程序；try-catch 本身几乎不耗性能。
为什么 throw 比 catch 慢上百倍？
每次执行 throw new RuntimeException()，JVM 必须做三件高开销的事：遍历整个调用栈、为每个栈帧生成 StackTraceElement 对象、把它们拼成字符串数组填进异常对象。这个过程涉及大量内存分配和字符串操作，实测耗时常达 1–10ms —— 是空方法调用的 50–200 倍。
- 堆栈越深（比如嵌套 10 层以上的方法调用），开销越大
- 频繁抛出（如每毫秒一次）会显著抬升 GC 压力，尤其在老年代触发 Minor GC
-
catch块本身无成本：HotSpot JIT 在没异常时完全内联 try 区域，不插入检查指令
哪些写法是典型的“用异常控流程”陷阱？
这类写法看着简洁，实际把可预测的业务分支交给了昂贵的异常机制，是性能最常被拖垮的源头。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
Integer.parseInt(str)后靠catch (NumberFormatException)判断是否为数字 → 改用str.matches("\d+")或 Guava 的Ints.tryParse(str) -
map.get(key).toString()不判空，靠NullPointerException捕获做 fallback → 改用map.getOrDefault(key, "default")或Optional.ofNullable(map.get(key)) - 数据库查询用
JpaRespository.findById(id)后直接.get()，靠NoSuchElementException处理不存在 → 改用.isPresent()或返回Optional<T>
真要抛异常时，怎么减点开销？
当 I/O 故障、网络超时等不可预知错误必须走异常路径时，可小幅优化构造成本，但不能牺牲可调试性。
立即学习“Java免费学习笔记（深入）”；
- 自定义异常类中重写
fillInStackTrace()返回this（仅限调试信息不重要、高频触发的场景，如内部状态机错误） - JDK 8+ 可用构造参数关闭堆栈：
new RuntimeException("", null, false, false) - 避免在
catch里重复打印：用 SLF4J 时写logger.error("读取配置失败", e)即可，别再加e.printStackTrace() - 高频但语义明确的错误（如 HTTP 404、401），考虑封装成
Result<T>类型，用code+message替代抛出IOException
真正难的不是知道“不该乱 throw”，而是上线后从监控里发现某段逻辑每秒抛出几百次 NumberFormatException —— 那往往意味着上游数据格式已变，而代码还在用异常兜底。这时候性能问题只是表象，根子在契约失效。
