Does try-catch Impact Java Performance? Bytecode & JIT Benchmark Analysis

JVM Exception Handling Logic

Java exceptions are thrown via the athrow bytecode instruction. The JVM automatically throws runtime exceptions (e.g., NullPointerException, division by zero) when detected. Catch blocks are not implemented with bytecode instructions (the old jsr / ret were discarded long ago); instead, the JVM uses an exception table stored in the method's Code attribute.

The author demonstrates with a simple add method that divides 100 by x inside a try block and catches any exception. Using javap -verbose, the compiled bytecode shows:

public int add(int);
  descriptor: (I)I
  flags: ACC_PUBLIC
  Code:
    stack=2, locals=3, args_size=2
       0: bipush        100
       2: iload_1
       3: idiv
       4: istore_1
       5: goto          11
       8: astore_2
       9: bipush        100
      10: istore_1
      11: iload_1
      12: ireturn
    Exception table:
       from    to  target type
           0     5     8   Class java/lang/Exception
    LineNumberTable:
      line 6: 0
      line 9: 5
      line 7: 8
      line 8: 9
      line 10: 11
    StackMapTable: number_of_entries = 2
      frame_type = 72 /* same_locals_1_stack_item */
        stack = [ class java/lang/Exception ]
      frame_type = 2 /* same */

The exception table entry from=0, to=5, target=8 covers the try block (bytecodes 0‑5). If an exception of type java/lang/Exception occurs in that range, control jumps to bytecode 8 (the catch block). When no exception occurs, the goto 11 at bytecode 5 skips the catch block entirely. The author notes that the only overhead in the no‑exception case is a single goto instruction, which is negligible compared to hundreds of bytecodes in a typical method.

JVM Compilation Optimizations

Tiered Compilation

The JVM runs in either Client (C1) or Server (C2) mode, each with its own JIT compiler. Tiered compilation combines interpretation, C1 compilation, and C2 compilation. The author's environment runs in Server mode, so the C2 compiler is used for hot‑spot optimization.

JIT Compiler Flags Used for Testing

Interpreted mode (no JIT): -Xint -XX:-BackgroundCompilation Compiled mode (max JIT):

-Xcomp -XX:CompileThreshold=10 -XX:-UseCounterDecay -XX:OnStackReplacePercentage=100 -XX:InterpreterProfilePercentage=33

These flags force early compilation and disable counter decay so that the test methods become hot quickly and are fully optimized.

AOT Compilation (jaotc)

Briefly mentioned: AOT compilation (based on Graal) can pre‑compile code to machine code before runtime, but it only supports G1/Parallel GC and requires JDK 9+. Not used in the benchmarks.

Benchmark Design

Each test method performs 10 million floating‑point additions (100 000 outer iterations × 10 inner additions). The outer loop runs 50 times and the median (mode) is taken to reduce noise. Five variants are tested: executeMillionsNoneTry – no try‑catch executeMillionsOneTry – single try‑catch wrapping the whole loop executeMillionsEveryTry – try‑catch inside each iteration executeMillionsEveryTryWithFinally – try‑catch‑finally inside each iteration (finally adds five more additions) executeMillionsTestReOrder – four separate try‑catch blocks per iteration to explore instruction‑reordering effects

// Example: try‑catch inside the loop
public void executeMillionsEveryTry() {
    float num = START_NUM;
    long start = System.nanoTime();
    for (int i = 0; i < TIMES; ++i) {
        try {
            num = num + STEP_NUM + 1f;
            num = num + STEP_NUM + 2f;
            num = num + STEP_NUM + 3f;
            num = num + STEP_NUM + 4f;
            num = num + STEP_NUM + 5f;
            num = num + STEP_NUM + 1f;
            num = num + STEP_NUM + 2f;
            num = num + STEP_NUM + 3f;
            num = num + STEP_NUM + 4f;
            num = num + STEP_NUM + 5f;
        } catch (Exception e) { }
    }
    long nao = System.nanoTime() - start;
    // ... output
}

Results: Interpreted Mode (-Xint)

Even with a try‑catch inside every iteration (100 000 iterations), the difference is only 5‑7 ms over 10 million operations. The author attributes the tiny gap to the extra goto bytecodes; in real‑world methods with hundreds of bytecodes, the relative cost is even smaller.

Results: Compiled Mode (-Xcomp)

With full JIT optimization, all variants are statistically indistinguishable – fluctuations are in microseconds. The JIT compiler eliminates the goto overhead entirely. Even scaling to 100 million operations shows only millisecond‑level variance.

Practical Example: Exception vs. Null Check

The author compares two approaches for decoding a URL parameter from a JSON object:

// Relies on catching NullPointerException
private int getThenAddNoJudge(JSONObject json, String key) {
    if (Objects.isNull(json)) throw new IllegalArgumentException("参数异常");
    int num;
    try {
        num = 100 + Integer.parseInt(URLDecoder.decode(json.get(key).toString(), "UTF-8"));
    } catch (Exception e) {
        num = 100;
    }
    return num;
}

// Explicit null check
private int getThenAddWithJudge(JSONObject json, String key) {
    if (Objects.isNull(json)) throw new IllegalArgumentException("参数异常");
    int num;
    try {
        num = 100 + Integer.parseInt(URLDecoder.decode(Objects.toString(json.get(key), "0"), "UTF-8"));
    } catch (Exception e) {
        num = 100;
    }
    return num;
}

Running each 1 million times shows that the version throwing and catching an exception every iteration is dramatically slower (because exception creation/stack‑trace capture is expensive), while the version with an explicit null check runs at the same speed as the no‑exception baseline. The lesson: try‑catch itself is free when no exception occurs; the cost comes from actually throwing exceptions.

Conclusion

"Java try‑catch severely impacts performance" is a myth. When no exception is thrown, the overhead is a single goto bytecode, which is negligible. JIT compilation removes even that. Developers should prioritize correctness and robustness; use try‑catch where needed. The real performance killer is throwing exceptions in hot paths, not the try‑catch construct itself.