我用JVM 1.5做了一些性能测试，使用异常至少慢了两倍。平均:一个非常小的方法的执行时间超过3倍(3倍)。一个必须捕获异常的小循环的自时间增加了2倍。

我在产品代码和微基准测试中也看到过类似的数字。

异常绝对不应该用于任何频繁调用的东西。每秒抛出数千个异常将导致巨大的瓶颈。

例如，使用“Integer.ParseInt(…)”在一个非常大的文本文件中找到所有错误的值——非常糟糕的想法。(我曾在产品代码上看到过这种实用方法的性能下降)

使用异常在用户GUI表单上报告错误的值，从性能的角度来看可能并不是那么糟糕。

无论这是否是一个好的设计实践，我都会遵循这样的规则:如果错误是正常的/预期的，那么就使用返回值。如果不正常，请使用异常。例如:读取用户输入，错误值是正常的—使用错误代码。将值传递给内部实用程序函数时，应该通过调用代码来过滤坏值——使用异常。

前段时间，我写了一个类来测试将字符串转换为整数的相对性能，使用两种方法:(1)调用Integer.parseInt()并捕获异常，或者(2)用正则表达式匹配字符串并仅在匹配成功时调用parseInt()。我以最有效的方式使用正则表达式(即，在终止循环之前创建Pattern和Matcher对象)，并且我没有打印或保存异常的堆栈跟踪。

对于一个包含10,000个字符串的列表，如果它们都是有效数字，那么parseInt()方法的速度是regex方法的四倍。但如果只有80%的字符串是有效的，则regex的速度是parseInt()的两倍。如果20%是有效的，这意味着异常在80%的时间内被抛出和捕获，则regex的速度大约是parseInt()的20倍。

我对结果感到惊讶，因为regex方法处理了两次有效字符串:一次用于匹配，另一次用于parseInt()。但是抛出和捕获异常完全弥补了这一点。这种情况在现实世界中不太可能经常发生，但如果发生了，您绝对不应该使用异常捕获技术。但如果您只是验证用户输入或类似的东西，务必使用parseInt()方法。

供你参考，我扩展了Mecki做的实验:

method1 took 1733 ms, result was 2
method2 took 1248 ms, result was 2
method3 took 83997 ms, result was 2
method4 took 1692 ms, result was 2
method5 took 60946 ms, result was 2
method6 took 25746 ms, result was 2

前3个和Mecki的一样(我的笔记本电脑明显慢一些)。

method4和method3是一样的，除了它创建了一个新的Integer(1)而不是抛出一个新的Exception()。

method5类似于method3，除了它创建了新的Exception()而不抛出它。

Method6和method3很像，只是它会抛出一个预先创建的异常(一个实例变量)，而不是创建一个新异常。

在Java中，抛出异常的大部分开销是收集堆栈跟踪所花费的时间，这发生在创建异常对象时。抛出异常的实际成本虽然很大，但比创建异常的成本要小得多。

Aleksey Shipilëv做了一个非常彻底的分析，他在各种条件组合下对Java异常进行了基准测试:

新创建的异常vs预先创建的异常 启用与禁用堆栈跟踪 请求的堆栈跟踪vs从未请求的堆栈跟踪 在顶层捕获vs在每一层重新抛出vs在每一层被链接/包裹 不同级别的Java调用堆栈深度 无内联优化vs极端内联vs默认设置 用户定义字段读与不读

他还将它们与在不同错误频率级别检查错误代码的性能进行了比较。

结论(逐字摘自他的帖子)如下:

Truly exceptional exceptions are beautifully performant. If you use them as designed, and only communicate the truly exceptional cases among the overwhelmingly large number of non-exceptional cases handled by regular code, then using exceptions is the performance win. The performance costs of exceptions have two major components: stack trace construction when Exception is instantiated and stack unwinding during Exception throw. Stack trace construction costs are proportional to stack depth at the moment of exception instantiation. That is already bad because who on Earth knows the stack depth at which this throwing method would be called? Even if you turn off the stack trace generation and/or cache the exceptions, you can only get rid of this part of the performance cost. Stack unwinding costs depend on how lucky we are with bringing the exception handler closer in the compiled code. Carefully structuring the code to avoid deep exception handlers lookup is probably helping us get luckier. Should we eliminate both effects, the performance cost of exceptions is that of the local branch. No matter how beautiful it sounds, that does not mean you should use Exceptions as the usual control flow, because in that case you are at the mercy of optimizing compiler! You should only use them in truly exceptional cases, where the exception frequency amortizes the possible unlucky cost of raising the actual exception. The optimistic rule-of-thumb seems to be 10^-4 frequency for exceptions is exceptional enough. That, of course, depends on the heavy-weights of the exceptions themselves, the exact actions taken in exception handlers, etc.

结果是，当没有抛出异常时，您不会付出代价，因此当异常条件足够罕见时，异常处理比每次都使用if更快。这篇文章的全文非常值得一读。

It depends how exceptions are implemented. The simplest way is using setjmp and longjmp. That means all registers of the CPU are written to the stack (which already takes some time) and possibly some other data needs to be created... all this already happens in the try statement. The throw statement needs to unwind the stack and restore the values of all registers (and possible other values in the VM). So try and throw are equally slow, and that is pretty slow, however if no exception is thrown, exiting the try block takes no time whatsoever in most cases (as everything is put on the stack which cleans up automatically if the method exists).

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

.．.但你是在用Java写代码，所以你的代码以后只能在一个特定系统的一个JVM上运行吗?因为如果它可以在任何其他平台或任何其他JVM版本(可能是任何其他供应商的)上运行，谁说他们也使用快速实现呢?速度快的要比速度慢的复杂得多，而且不容易在所有系统上实现。你想要便携吗?那就不要指望异常会很快。

It also makes a big difference what you do within a try block. If you open a try block and never call any method from within this try block, the try block will be ultra fast, as the JIT can then actually treat a throw like a simple goto. It neither needs to save stack-state nor does it need to unwind the stack if an exception is thrown (it only needs to jump to the catch handlers). However, this is not what you usually do. Usually you open a try block and then call a method that might throw an exception, right? And even if you just use the try block within your method, what kind of method will this be, that does not call any other method? Will it just calculate a number? Then what for do you need exceptions? There are much more elegant ways to regulate program flow. For pretty much anything else but simple math, you will have to call an external method and this already destroys the advantage of a local try block.

请看下面的测试代码:

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块的减速太小，无法排除后台进程等混杂因素。但是catch block杀死了一切，让它慢了66倍!

正如我所说，如果将try/catch和throw都放在同一个方法(method3)中，结果不会那么糟糕，但这是我不依赖的特殊JIT优化。即使使用这种优化，抛出仍然非常慢。我不知道你们想做什么，但肯定有比try/catch/throw更好的方法。

我用JVM 1.5做了一些性能测试，使用异常至少慢了两倍。平均:一个非常小的方法的执行时间超过3倍(3倍)。一个必须捕获异常的小循环的自时间增加了2倍。

我在产品代码和微基准测试中也看到过类似的数字。

异常绝对不应该用于任何频繁调用的东西。每秒抛出数千个异常将导致巨大的瓶颈。

例如，使用“Integer.ParseInt(…)”在一个非常大的文本文件中找到所有错误的值——非常糟糕的想法。(我曾在产品代码上看到过这种实用方法的性能下降)

使用异常在用户GUI表单上报告错误的值，从性能的角度来看可能并不是那么糟糕。

无论这是否是一个好的设计实践，我都会遵循这样的规则:如果错误是正常的/预期的，那么就使用返回值。如果不正常，请使用异常。例如:读取用户输入，错误值是正常的—使用错误代码。将值传递给内部实用程序函数时，应该通过调用代码来过滤坏值——使用异常。