Analyzing the Performance Impact of try-catch in Java

Introduction

There is a common belief that using try-catch in Java severely degrades performance; this article investigates whether that claim holds.

1. JVM Exception Handling Logic

Java throws exceptions via the athrow instruction; runtime exceptions like division by zero or NullPointerException are automatically thrown. Modern JVMs use an exception table rather than bytecode instructions (jsr/ret) to implement catch blocks, which explains why older performance concerns are outdated.

Example class TestClass demonstrates a method with a try-catch around a division operation. The compiled bytecode is shown using javap -verbose, revealing the instruction range (0‑5) for the try block and the target (8) for the catch block.

public class TestClass {
    private static int len = 779;
    public int add(int x) {
        try {
            // 若运行时检测到 x = 0, 那么 jvm 会自动抛出异常
            x = 100 / x;
        } catch (Exception e) {
            x = 100;
        }
        return x;
    }
}

The exception table maps the try range to the catch handler. If no exception occurs, execution jumps directly to instruction 11, so the overhead is negligible.

个人理解，from 和 to 相当于划分区间，只要在这个区间内抛出了 type 所对应的 "java/lang/Exception" 异常(主动 athrow 或者 由 jvm 运行时检测到异常自动抛出)，那么就跳转到 target 所代表的第八行。

Removing the try-catch reduces the bytecode size slightly, but the performance impact is minimal.

2. JVM Compilation Optimizations

The article outlines front‑end compilation (javac) and back‑end compilation (JIT and AOT). It describes client (C1) and server (C2) compilers, interpretation, compilation, and mixed modes.

2.1 Layered Compilation

JVM can run in interpreter mode, compilation mode, or a hybrid of both. Images illustrate the server mode using the C2 compiler.

2.2 JIT Compiler

Key JVM flags for forcing compilation, setting compile thresholds, disabling counter decay, and adjusting on‑stack replacement are listed:

# 强制虚拟机运行于 "编译模式"
-Xcomp
# 方法调用次数阈值 (Client=1500, Server=10000)
-XX:CompileThreshold=10
# 关闭方法调用次数热度衰减
-XX:-UseCounterDecay
# 设置 OSR 比率
-XX:OnStackReplacePercentage=100

2.3 Ahead‑of‑Time Compiler (jaotc)

Brief mention of Graal and AOT support in JDK 9+, with the flag -XX:PrintAOT to display information.

3. Test Constraints

Execution time is measured with System.nanoTime() over millions of iterations to ensure statistical significance.

4. Test Code

Various methods are provided to benchmark different try‑catch placements: no try, one outer try, try inside the loop, try with finally, and multiple nested tries.

public class ExecuteTryCatch {
    private static final int TIMES = 1000000;
    private static final float STEP_NUM = 1f;
    private static final float START_NUM = Float.MIN_VALUE;
    // ... (methods executeMillionsNoneTry, executeMillionsOneTry, executeMillionsEveryTry, etc.)
}

5. Tests in Interpreter Mode

Running with -Xint -XX:-BackgroundCompilation disables JIT. Results show that even with a million iterations, the added try‑catch incurs only a few milliseconds of overhead.

6. Tests in Compilation Mode

Running with JIT flags ( -Xcomp, etc.) makes the hotspot code compile, reducing the variance to microseconds and confirming that try‑catch does not hinder JIT optimizations.

7. Conclusion

Try‑catch does not cause significant performance degradation; developers should prioritize code robustness. In the absence of exceptions, wrapping code in try‑catch has negligible impact.