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 MacparseWithTryCatch_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或者返回一个默认值考虑一下这个异常是”真的例外”还是”被当成了正常情况处理”。