会，但仅在异常被抛出并实际处理时才产生显著性能开销；正常执行流程中使用 try-catch 本身几乎无成本。异常抛出是性能瓶颈的主因，核心开销来自 Throwable 构造时生成堆栈跟踪，涉及大量对象分配和字符串操作，比空方法调用慢百倍以上；频繁抛出会导致 GC 压力与 CPU 缓存失效；catch 块本身不慢，但每次进入意味着已发生昂贵抛出动作；应避免用异常做流程控制，如参数验证、空结果判断等场景应优先用预检或 Optional；必要时可通过关闭堆栈、重写 fillInStackTrace 或改用错误码优化；try-catch 语句本身编译后仅增异常表，JIT 未触发异常时完全内联，性能无损；关键在于区分“错误”与“预期之外的情况”，将异常留给真正异常的场景。
会，但仅在异常被抛出并实际处理时才产生显著性能开销；正常执行流
try-catch 本身几乎无成本。
异常抛出是性能瓶颈的主因
Java 异常的核心开销来自 Throwable 构造时自动生成堆栈跟踪（stack trace）——它会遍历当前线程所有栈帧，生成字符串并填充 StackTraceElement 数组。这一过程涉及大量对象分配和字符串操作，耗时远高于普通方法调用。
- 一次
new RuntimeException()可能比空方法调用慢 100 倍以上（实测常见于 1–10ms 量级） - 频繁抛出异常（如用异常控制业务流程）会导致 GC 压力上升、CPU 缓存失效
-
catch块本身不慢，但每次进入catch意味着已发生昂贵的抛出动作
避免用异常做流程控制
这是最常见也最易修复的性能陷阱。例如验证参数、解析字符串、查数据库结果为空等场景，应优先用返回值或状态判断，而非依赖 NumberFormatException 或 NullPointerException。
- ❌ 错误示范：
Integer.parseInt(str)然后靠捕获NumberFormatException判断是否为数字 - ✅ 正确做法：先用正则或
Character.isDigit()预检，或使用Ints.tryParse()（Guava）等不抛异常的工具方法 - 数据库查询结果为空，用
Optional或if (rs.next())判断，而非靠NoResultException走异常分支
优化异常使用本身的技巧
当异常确实必要（如 I/O 故障、网络超时），可通过减少开销提升效率：
- 重写
fillInStackTrace()返回this（适用于自定义异常且不需要堆栈信息的场景，慎用） - 使用构造函数入参关闭堆栈（JDK 8+ 支持
new RuntimeException("", null, false, false)） - 对高频但可预期的错误（如 HTTP 404），考虑封装为带错误码的普通返回对象，而非抛出检查型异常
- 日志记录异常时，优先打印
e.getMessage()，避免高频调用e.printStackTrace()（后者会触发完整堆栈格式化）
编译期与 JIT 的影响很小，不必过度关注
try-catch 语句块本身在字节码中只是添加异常表（exception table），不增加运行时指令；HotSpot JIT 在未触发异常时完全内联相关代码，性能与无 try 相同。因此：
- 不要因为“怕影响性能”而完全不用
try-catch - 也不必为了“性能”把所有异常都转成错误码——可读性与正确性优先
- 真正要监控的是
Exception实例的创建频率（如通过 JVM native memory tracking 或 Arthas 观察）
基本上就这些。异常不是洪水猛兽，关键是分清“错误”和“预期之外的情况”，把异常留给真正异常的场景。
