会，但仅在异常被抛出时才产生显著性能开销；try-catch本身几乎零成本，核心开销来自fillInStackTrace()遍历调用栈、生成堆栈元素及字符串数组，耗时1–10ms，远超空方法调用。
会，但仅在异常被抛出时才产生显著性能开销；try-catch语句本身几乎不拖慢程序——只要没真抛异常，JIT 会完全内联它，零成本。
为什么 new RuntimeException() 比空方法慢 100 倍？
核心开销来自 Throwable 构造时调用 fillInStackTrace()：它要遍历整个调用栈，为每个栈帧生成 StackTraceElement，再拼成字符串数组。这个过程涉及大量对象分配、字符拷贝和内存访问，实测耗时常达 1–10ms 级别。
- 一次
new IllegalArgumentException("bad")的开销 ≈ 100+ 次空方法调用 - 频繁抛出（如每毫秒一次）会快速推高 GC 压力，尤其触发 Young GC 频率上升
-
catch块本身不慢，但它出现的前提是已经发生了昂贵的抛出动作
哪些场景最容易误用异常做流程控制？
这是最常见、也最容易修复的性能陷阱。本质是把“可预期的业务分支”当成了“不可预料的错误”。
-
数字解析：
Integer.parseInt(str)+catch NumberFormatException→ 改用Ints.tryParse(str)（Guava）或正则预检str.matches("\\d+") -
数据库查询为空：依赖
NoResultException→ 改用if (rs.next())或返回Optional -
空值判断：靠
NullPointerException触发 fallback → 提前用Objects.nonNull(obj)或Optional.ofNullable(obj).orElse(...) -
HTTP 状态码处理：对 404/400 抛
HttpClientErrorException→ 封装为Result类型，用isSuccess()+errorCode判断
如何安全地降低异常开销？
不是所有异常都能删掉，I/O 超时、网络中断这类必须抛。关键是在保留诊断能力的前提下剪掉冗余成本。
立即学习“Java免费学习笔记（深入）”；
- 关闭堆栈（JDK 8+）：
new RuntimeException("", null, false, false)—— 第三、四参数分别禁用堆栈填充与抑制机制 - 重写
fillInStackTrace()：public class LightException extends RuntimeException { @Override public Throwable fillInStackTrace() { return this; } }（仅适用于完全不需要堆栈信息的高频内部错误） - 日志中避免
e.printStackTrace()：改用logger.error("Failed to parse: {}", str, e)，让 SLF4J 惰性格式化；生产环境 DEBUG 级以下不打完整堆栈 - 把
try-catch移出循环：❌ 在 for 内 try；✅ 先批量校验，再统一处理
真正难的不是知道“不该用异常控制流程”，而是识别哪些看似异常的情况其实属于业务常态——比如用户输错手机号、第三方 API 返回临时限流、缓存未命中。这些不是 bug，是设计的一部分。把它们从 throw 挪到 if 里，性能提升立竿见影，代码也更诚实。
