try-catch到底有没有性能开销

有一种说法是”try-catch 有性能开销，关键路径上不要用”。另一种说法是”try-catch 不抛异常的话没有开销”。这两种说法都不全对，开销在哪里要看具体用法。

try-catch 本身不贵，异常对象才贵

JVM 里，try-catch 的实现方式是在字节码里维护一张异常表（exception table），记录哪段代码对应哪些异常处理器。不抛异常的时候，代码直接顺序执行，不查异常表。JIT 编译器对没有异常的热路径做了充分优化，try { ... } catch (...) { }的包裹本身开销可以忽略不计。

开销来自于异常对象的创建：

throw new RuntimeException("something went wrong");

这行代码做了什么？RuntimeException的构造方法调用父类Throwable的构造方法，其中有一步叫fillInStackTrace()。这个方法遍历当前线程的整个调用栈，把每一帧的类名、方法名、行号都记录下来，生成一个StackTraceElement[]数组。

调用栈如果有 30 层（Spring Boot 的接口里很正常），就是 30 次字符串操作、30 次数组元素写入。这不是原子操作，是有明显成本的。加上对象内存分配，一次throw new Exception()的代价，通常比普通对象创建高一到两个数量级。

只要异常不频繁抛出，这个开销就不是问题——异常本来就是”例外情况”，偶尔抛一次代价无所谓。问题出在把异常当作控制流用。

用异常做控制流是个坏主意

// 有人这么做： try { int value = Integer.parseInt(input); return value; } catch (NumberFormatException e) { return -1; }

如果input大多数时候是数字，这没有问题。但如果这个方法每秒被调用几万次，而且input经常是非数字字符串，NumberFormatException就在每次调用时被创建，每次都调fillInStackTrace()，性能会差得很明显。

正确的写法是先判断，不依赖异常：

public static boolean isNumeric(String str) { if (str == null || str.isEmpty()) return false; for (char c : str.toCharArray()) { if (!Character.isDigit(c)) return false; } return true; }

类似的还有用NullPointerException判断 null（明确判断 null 不用靠 NPE），用ArrayIndexOutOfBoundsException判断边界（先检查length），这些都是把异常当正常控制流用的反模式。

想要”异常”但不要栈帧成本

有些场景需要通过异常机制传递信号，但不需要完整的栈追踪。典型的是某些框架里用异常做中断或流程跳转（Spring MVC 里就有这种用法）。

可以覆盖fillInStackTrace()，让它什么都不做：

public class FastException extends RuntimeException { public FastException(String message) { super(message); } @Override public synchronized Throwable fillInStackTrace() { return this; // 直接返回，不记录任何栈帧 } }

这样的异常创建成本接近普通对象，可以频繁使用。代价是没有栈追踪，出了问题日志里看不到调用链，调试时要自己传递上下文信息。框架里有这个用法，业务代码一般不需要。

实际项目里该注意什么

不要为了”性能”把该用 try-catch 的地方去掉。调用外部接口、解析用户输入、做 IO 操作，这些地方出现异常是预期内的，try-catch 处理掉是正确做法，这里的异常频率不高，性能不是问题。

真正需要注意的是循环里：

for (String str : items) { try { int value = Integer.parseInt(str); // 如果 str 经常不是数字，这里每次都抛异常 process(value); } catch (NumberFormatException e) { // skip } }

如果items里有大量非数字字符串，这个循环会频繁创建NumberFormatException对象。换成先判断的写法，或者用NumberUtils.isCreatable()（Apache Commons Lang），不靠异常控制流。

还有一种情况是日志里e.printStackTrace()——这会把完整栈追踪打到标准错误，不仅有栈追踪生成的成本，还有大量字符串拼接和 IO 的成本。用日志框架打异常：log.error("failed", e)，不要e.printStackTrace()。

JMH 实测数据

说了半天”有开销”、”代价高”，到底差多少？用 JMH 实际跑一下：

@BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 5, time = 1) @Measurement(iterations = 5, time = 1) @Fork(1) public class TryCatchBenchmark { private static final String VALID = "12345"; private static final String INVALID = "abc"; @Benchmark public int parseWithTryCatch_valid() { try { return Integer.parseInt(VALID); } catch (NumberFormatException e) { return -1; } } @Benchmark public int parseWithTryCatch_invalid() { try { return Integer.parseInt(INVALID); } catch (NumberFormatException e) { return -1; } } @Benchmark public int parseWithCheck_invalid() { for (char c : INVALID.toCharArray()) { if (!Character.isDigit(c)) return -1; } return Integer.parseInt(INVALID); } }

典型结果（JDK 17、M1 Mac）：

parseWithTryCatch_valid：约 8 ns——正常路径没有额外开销。parseWithTryCatch_invalid：约 1200-1500 ns——异常路径慢了两个数量级。parseWithCheck_invalid：约 4 ns——先判断几乎没有成本。

1500 ns 单独看不多，但如果在一个循环里每秒触发几万次异常，累积起来就是几十毫秒的 CPU 时间。在 GC 层面，频繁创建的异常对象还会增加 Young GC 的频率——StackTraceElement[]数组每次都是新的对象分配。

异常表对 JIT 优化的影响

try-catch 在热路径上还有一个隐含影响：JIT 编译器在内联优化时会考虑异常表的范围。如果一个方法包含 try-catch 且被 JIT 内联，异常表需要在内联后重新映射。某些情况下，过深的 try-catch 嵌套或者过大的 try 块会让 JIT 放弃部分内联优化（MaxInlineLevel和MaxInlineSize的限制更容易触及），导致整体方法的运行速度略慢。

这个影响在绝大多数业务代码里可以忽略。但如果用 JMH 测某个热方法发现有 try-catch 和没有 try-catch 差了几个 ns，原因可能不是异常表的查询开销，而是 JIT 在内联策略上做了不同选择。

try-catch 包裹没有运行时开销，new Exception()有明显开销（主要是fillInStackTrace()），用异常做正常控制流在高频场景下是真实的性能问题。检查一下代码里的 catch 块，如果里面是// ignore或者返回一个默认值，考虑一下这个异常是”真的例外”还是”被当成了正常情况处理”。