“异常会影响性能吗？”这个问题，我在面试 Java 进阶岗时问过不少人，也在生产环境里被真实打脸过。大多数人能背出“异常创建成本高、填充堆栈很耗时”这样的结论，但问到“高在哪、量级差多少、什么时候才值得优化”，能讲清楚的很少。这篇文章不聊八股，我把底层机制、HotSpot 的隐藏优化、实测数据、优化取舍和踩坑记录一次性讲透，适合正在做 Java 进阶、准备面试、或者被线上异常日志搞到头大的同学。
先说结论：try-catch 本身几乎不要钱，真正贵的是 throw 之后那一整套动作。但这个成本不是绝对的，它跟异常频率、调用栈深度、是否打印堆栈、是否触发 JIT 快速路径都有关系。不量化就优化的行为，跟不看火焰图就乱拆代码一样危险。
1. 先拆开看：异常的成本到底花在哪
1.1 try 块本身：一道几乎不花钱的护栏
如果你以为 try 块内部的代码会比普通代码执行得慢，那就误会了。从字节码层面看，try-catch 并不是在每行代码前后插入检查点，而是生成一张异常表，记录 try 范围的起始偏移量、结束偏移量和 catch 处理器的跳转偏移量。正常路径下，CPU 根本不会去看这张表，只有异常实际抛出时才按表查找匹配的处理器。
这有点像你开车经过一段有护栏的路段，护栏本身不会让你的车速下降，只有真的撞上去才会花时间处理。JIT 将 try 块编译成机器码后，同样不会额外加入异常检查指令。所以“try 块让代码变慢”这个说法基本不成立，真正影响性能的是两个东西：异常对象的创建和堆栈轨迹的填充。
很多团队一看到 try-catch 就担心性能，宁可让异常冒泡到底层也不加处理，其实完全没必要。try 块本身的开销在纳秒级别，写不写它、写得散不散，对性能的影响微乎其微。问题的核心在于：你有没有在异常路径上频繁地“throw + catch + 打印堆栈”。
1.2 真正的大头：异常对象与堆栈轨迹填充
Java 里每次 throw 都是一个Throwable子类的实例化过程。这个 new 操作本身不贵，贵在构造阶段会调用fillInStackTrace()，这是个 native 方法，它会从当前线程的栈帧中抓取所有调用点，生成StackTraceElement数组。
栈帧越深，这个数组越长，成本也跟着线性上涨。一个方法调用深度在 20 到 30 层的项目里，每次填充堆栈的耗时通常在数微秒到几十微秒之间，而普通方法调用本身是几纳秒级别。换句话说，单纯执行一次“抛异常并被捕获”的动作，可能比一次普通方法调用慢两到三个数量级。
打个比方，普通方法调用就像顺手从抽屉里取一张便利贴；抛异常则像你不仅要把便利贴塞进信封，还得打印出这封信经过的所有中转站地址，最后盖上邮戳寄出去。如果只是偶尔寄一封信，没什么感觉；如果业务代码每秒要寄几万封，光打印中转站地址就能把邮局拖垮。
异常还会带来 GC 压力。逃逸出的异常对象会被分配到堆上，StackTraceElement 数组和背后引用的字符串都是额外对象，这些都会增加 Young GC 的频率。所以大量抛异常不只是 CPU 问题，还是一个隐藏的内存分配问题。
2. HotSpot 的隐藏“加速”与踩坑记录
2.1 OmitStackTraceInFastThrow：一剂疗效猛但有副作用的药
HotSpot 有一个非常经典的优化开关：OmitStackTraceInFastThrow，非常坑。默认它是开启的。当 JIT 编译器识别到同一个异常类在同一个抛出点被非常频繁地触发时，会启动一条快速路径，直接抛出一个预先分配好的、没有堆栈轨迹的异常实例，绕过fillInStackTrace()这个昂贵动作。
这个优化理论上很合理：既然这个位置反反复复抛同一种异常，堆栈内容大概率都是同一段，每次花几微秒去填栈纯属浪费。但对排查问题的工程师来说，它是个灾难。线上大量异常日志里，你会看到同一行日志有时候带着完整堆栈，有时候只有一行：
java.lang.NullPointerException没有 at 开头的栈帧，没有调用来源。第一次看到的人会以为程序出 bug 了，或者日志框架坏了，其实真正原因是 HotSpot 已经开始用快速路径。而且这个“fast throw”异常实例是共享的，后续所有同类异常都指向同一个对象，如果你有人手动修改异常对象的状态来加一些业务信息，会酿成更大的问题。
排查时如果发现堆栈缺失，第一反应应该是查看是否触发了这个优化。确认方式很简单：在 JVM 启动参数加-XX:-OmitStackTraceInFastThrow关掉快速路径，再观察日志。但我建议不要长期关闭它——高频异常的堆积本身已经是问题，保留快速路径至少能把 CPU 成本压下来，正确做法是修复源头，而不是让 JVM 帮你硬扛。
2.2 逃逸分析、栈上分配与异常对象的宿命
除了快速路径，逃逸分析也会影响异常的性能。JIT 编译器会分析异常对象是否逃逸出当前方法。如果一个异常在方法内部被抛出、又被同一个方法里的 catch 捕获，且没有被传递出去，理论上存在被标量替换或栈上分配的可能，分配成本会大幅降低。
但现实是，绝大多数异常对象是要逃逸的——你抛出它就是为了让上层调用者感知并处理，它会沿着调用栈往上传递，逃逸分析自然失效，只能老老实实堆分配。
所以当你设计一个异常基准测试时，如果不注意控制逃逸分析的影响，可能会测出一个极其“乐观”的结果，看起来抛异常也不怎么慢，其实是 JIT 帮你把根本没有逃逸的异常给优化没了。真正的生产路径上，异常对象大多数都逃逸了，那个成本才是你需要在意的。
3. 现场实测：一次可控的基准测试与解读
3.1 基准设计：正常返回 vs 抛异常 vs 异常+打印堆栈
为了不让结论停留在理论层面，我写了一个简单的 JMH 基准，在 JDK 17 下对比三种路径的吞吐。
@State(Scope.Thread) @BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.MICROSECONDS) @Fork(value = 2, jvmArgsAppend = { "-XX:+PrintGCDetails" }) public class ExceptionBenchmark { private final int value = 10; @Benchmark public int normalReturn() { return value; } @Benchmark public int throwAndCatch() { try { return risky(); } catch (IllegalArgumentException e) { return 0; } } @Benchmark public int throwAndPrint() { try { return risky(); } catch (IllegalArgumentException e) { e.printStackTrace(); return 0; } } private int risky() { return value + 1; } }需要提醒的是，上面的risky()并不会真的抛异常，我必须在每次调用时特意抛出一个IllegalArgumentException才能对比“抛出路径”和“正常路径”，但在 JMH 里把抛异常写进被测方法会导致编译器内联行为复杂化。所以更贴近实战的做法是在被测方法里显式抛异常：
@Benchmark public int throwAndCatch() { try { throw new IllegalStateException("simulated"); } catch (IllegalStateException e) { return 0; } }这类基准的结果在不同机器、不同 JDK 版本上波动很大，但量级规律基本稳定：正常返回是纳秒到几十纳秒；抛异常并被捕获是微秒量级，通常比正常路径慢出几百倍；如果再加上printStackTrace()把内容打到磁盘或控制台，那就不再是 CPU 问题，而是 I/O 直接把系统拖死。
3.2 测试中的三个坑
第一个坑是快速路径干扰。如果你测的是“同一个抛出点高频抛异常”，JIT 很可能在预热阶段就启用了快速路径，导致你测出来的“抛异常成本”已经是被优化过的。想看到真实的堆栈填充开销，要用-XX:-OmitStackTraceInFastThrow关闭快速路径再跑一轮对比。
第二个坑是输出流干扰。很多人一测异常性能就把printStackTrace()写进基准里，结果是控制台或日志文件被刷爆，几兆字节的 I/O 输出完全掩盖了异常本身的成本，测出来的数字没有任何参考意义。真实场景中，打印堆栈的成本往往比抛异常高得多，但这是两笔账，必须分开算。
第三个坑是逃逸分析的作弊效果。如果异常对象始终被同一个方法捕获且不传递出去，JIT 可能彻底消除分配甚至消除抛出动作本身，测出来的吞吐高得离谱。为了让测试贴近生产，建议把异常抛出的方法拆成独立方法，让异常对象通过方法返回值或参数逃逸到上层。
4. 不是所有异常都值得优化——按场景做取舍
4.1 可预期分支上的一类“假异常”
有些开发同学喜欢用异常做流程控制，最常见的就是数据解析：传进来一个字符串，判断不了格式就直接抛异常让上游去处理。这种写法在低频率场景问题不大，但一旦进入批量任务或高并发接口，就会变成性能陷阱。
举个经典例子：
public static int toInt(String input) { try { return Integer.parseInt(input); } catch (NumberFormatException e) { return 0; } }这段代码在非法输入很少时没什么问题，但如果这个toInt被用在每天几百万次调用的清洗任务里，而输入里又有大批非数字，NumberFormatException就会高频出现，每次异常还要额外构造堆栈，CPU 和 GC 双双受损。改成先做一轮字符级预校验，或者用预编译正则匹配，能在源头上降低异常触发频率。
不过我要说句公道话：如果非法输入率本来就极低，比如一万次才碰上一次，那这种优化并不紧急，不要本末倒置。优化的前提是先通过火焰图或 JFR 确认这段代码确实是热点，而不是凭感觉“看到 try-catch 就觉得有问题”。
4.2 该抛就抛，别为了性能砸掉语义
另一类场景恰恰相反：异常必须用，而且应该大胆用。比如 IO 读取失败、数据库连接异常、外部接口返回非法状态、资源关闭失败、参数校验不合格且调用方必须感知并处理——这些都是强语义场景，用错误码根本说不清楚到底错在哪。
最常见的反模式是吞异常：
try { orderService.submit(order); } catch (Exception e) { // 先放着 }这种代码短期内看不出性能问题，因为它连异常对象都没怎么构造，但它会把问题隐藏到生产环境，让你在凌晨三点凭着一行“订单未提交”去猜原因。性能优化永远不应该以牺牲语义清晰为代价。如果觉得异常对象太贵，优先考虑的是减少触发频率，而不是删掉异常处理。
4.3 自定义异常：如何在不丢掉语义的前提下省成本
我在实际项目中确实用过一种省成本的小技巧：重写fillInStackTrace()，让异常对象跳过堆栈填充。
public class FastBusinessException extends RuntimeException { private final long timestamp; private final String requestId; public FastBusinessException(String message, String requestId) { super(message); this.timestamp = System.currentTimeMillis(); this.requestId = requestId; } @Override public synchronized Throwable fillInStackTrace() { return this; } }这样写的好处是：异常对象仍然保留类型、消息、业务流水号和时间戳这些关键信息，但省掉了堆栈扫描和字符串分配，单次抛出的成本会明显下降。坏处是异常日志里看不到调用来源，所以这种类只适合用在语义明确、位置固定、不需要依赖堆栈定位的校验型异常上，绝不能一股脑用到所有异常上。
还有一个小经验，给自定义异常加一个请求 ID 和时间戳字段，往往比完整堆栈更有实战价值。线上排查时，根据 requestId 直接查到整条链路，不需要靠堆栈一层层翻。这一点在分布式链路追踪场景下尤其重要。
5. 面试视角：这个问题应该怎么答
5.1 一套可以直接用的回答框架
如果你的面试官问“异常影响性能吗”，别急着答“影响”或“不影响”。一个成熟的回答应该分四层：
先说定性：try 块本身开销接近零，开销集中在 throw 后对象创建和堆栈填充。再给定量：正常路径纳秒级，抛异常加捕获微秒级，慢两到三个数量级；打印堆栈的话还要加上 IO 成本。然后讲机制：为什么fillInStackTrace贵，HotSpot 的OmitStackTraceInFastThrow快速路径如何在特定条件下自动降级。最后谈取舍：只有在热路径高频触发时才值得优化，优化手段包括前置校验避免抛异常、用返回结果对象替代异常做分支表达、自定义异常跳过堆栈填充。
这套回答不仅覆盖了性能，还展示了你对 JVM 底层行为和工程实践的完整理解，比单纯背结论强得多。
5.2 面试官常追问的三个问题
追问一：“try 和 catch 哪个更影响性能？” 答：try 块本身不影响，catch 块也不影响，影响的是 throw 后的异常对象创建和堆栈填充。但 catch 块里如果放了打印日志、重试逻辑这种重量级操作，那另说。
追问二：“为什么线上日志会出现只有一行没有堆栈的异常？” 答：大概率是 HotSpot 开启了快速路径，省略堆栈填充。可以通过-XX:-OmitStackTraceInFastThrow验证，但真正要解决的是高频异常本身。
追问三：“你会用错误码代替异常吗？” 答：不会全盘替换。正常业务流程里可预期的分支可以用状态码或 Optional 表达，外部依赖失败、IO 异常、参数非法这种必须由调用方处理的错误，保留异常更利于维护。性能问题应当量化后再决定是否重构。
6. 一处亲身经历的优化复盘
最后分享一个我实际做过的优化。有个网关项目，早期业务校验逻辑里大量使用自定义业务异常来标识参数缺失或状态不允许，比如用户请求里少了某个必填参数，就抛一个BizException让统一异常处理器返回包装后的 JSON。
最开始每天的异常量只有几百次，谁也没在意。后来接入的业务方多了，单日异常量涨到百万级别，某几个热门接口的 p99 延迟开始明显上升。我用 JFR 采样后发现，Throwable.fillInStackTrace在火焰图上的占比已经高到离谱，远超大部分业务逻辑本身。
当时的修复不是一刀切禁用异常，而是做了三件事：把参数缺失这类“可预期分支”改成返回一个校验结果对象，走正常返回值而不是抛出异常链路；保留BizException给真正需要中断处理的错误场景，但重写了fillInStackTrace跳过硬堆栈填充，同时加上 requestId 字段；最后统一异常处理器的日志策略，禁止在已知业务异常上打印完整堆栈，只记录消息和 requestId。改造后，相关接口的延迟回落明显，GC 压力也跟着降了。
如果你也打算做类似的优化，我的建议是先量化，再动手。先用火焰图或 JFR 确认异常相关开销确实占比高，再决定是降低触发频率、减少堆栈填充还是调整日志输出。不要因为听说异常影响性能，就把业务代码里所有异常全都替换成错误码。真正的病根通常不是异常本身，而是把异常用在了错误的地方——或者让高频异常跑了满血版的堆栈填充。
