Java 中异常对性能的影响是什么

这取决于如何实现异常.最简单的方法是使用setjmp和long jmp.这意味着CPU的所有寄存器都被写入堆栈(这已经需要一些时间)，并且可能需要创建一些其他数据……所有这些都已经在try语句中发生了.Throw语句需要展开堆栈并恢复所有寄存器的值(以及VM中可能的其他值).因此try 和抛出一样慢，这是相当慢的，但是如果没有抛出异常，退出try 挡路在大多数情况下都不需要任何时间(因为所有东西都放在堆栈上，如果方法存在，堆栈会自动清理).

Sun和其他人认识到，这可能是次优的，当然，随着时间的推移，虚拟机的速度越来越快.还有另一种实现异常的方法，它使try本身闪电般地快(实际上try一般不会发生任何事情——当VM加载类时，所有需要发生的事情都已经完成了)，并且它使throw没有那么慢.我不知道哪个JVM使用这种新的、更好的技术...

...但是，您是在用Java编写代码，以便以后的代码只在一个特定系统的一个JVM上运行吗？既然它可能在任何其他平台或任何其他JVM版本(可能是任何其他供应商的版本)上运行，谁说他们也使用fast实现？快的比慢的复杂，而且不容易在所有系统上实现.你想随身携带吗？那就别指望异常会很快出现.

这也会让你在一个try块中做什么有很大的不同.如果您打开一个try块，并且从未从该try块中调用任何方法，那么try块将非常快，因为JIT实际上可以像处理简单的goto一样处理一次抛出.如果抛出异常，它既不需要保存堆栈状态，也不需要释放堆栈(只需要跳转到catch处理程序).然而，这不是你通常做的.通常你打开一个try块，然后调用一个可能引发异常的方法，对吗？即使你只是在你的方法中使用try块，这是什么样的方法，不调用任何其他方法？它会计算一个数字吗？那你为什么需要例外呢？有很多更优雅的方法来调节程序流.对于除简单数学之外的几乎任何东西，都必须调用外部方法，这已经 destruct 了本地try块的优势.

请参阅以下测试代码:

public class Test {
    int value;


    public int getValue() {
        return value;
    }

    public void reset() {
        value = 0;
    }

    // Calculates without exception
    public void method1(int i) {
        value = ((value + i) / i) << 1;
        // Will never be true
        if ((i & 0xFFFFFFF) == 1000000000) {
            System.out.println("You'll never see this!");
        }
    }

    // Could in theory throw one, but never will
    public void method2(int i) throws Exception {
        value = ((value + i) / i) << 1;
        // Will never be true
        if ((i & 0xFFFFFFF) == 1000000000) {
            throw new Exception();
        }
    }

    // This one will regularly throw one
    public void method3(int i) throws Exception {
        value = ((value + i) / i) << 1;
        // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
        // an AND operation between two integers. The size of the number plays
        // no role. AND on 32 BIT always ANDs all 32 bits
        if ((i & 0x1) == 1) {
            throw new Exception();
        }
    }

    public static void main(String[] args) {
        int i;
        long l;
        Test t = new Test();

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            t.method1(i);
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method1 took " + l + " ms, result was " + t.getValue()
        );

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            try {
                t.method2(i);
            } catch (Exception e) {
                System.out.println("You'll never see this!");
            }
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method2 took " + l + " ms, result was " + t.getValue()
        );

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            try {
                t.method3(i);
            } catch (Exception e) {
                // Do nothing here, as we will get here
            }
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method3 took " + l + " ms, result was " + t.getValue()
        );
    }
}

结果:

method1 took 972 ms, result was 2
method2 took 1003 ms, result was 2
method3 took 66716 ms, result was 2

try 挡路的放缓幅度太小，不能排除后台进程等混杂因素.但是抓到的挡路杀死了一切，使它慢了66倍！

正如我所说的，如果您将try/catch和抛出都放在同一个方法(Method 3)中，结果将不会那么糟糕，但这是一个我不会依赖的特殊JIT优化.即使在使用这种优化的情况下，投掷仍然相当缓慢.所以我不知道您在这里想做什么，但是肯定有一种比使用try/catch/jo更好的方法.