供你参考，我扩展了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中，抛出异常的大部分开销是收集堆栈跟踪所花费的时间，这发生在创建异常对象时。抛出异常的实际成本虽然很大，但比创建异常的成本要小得多。

比较一下，假设是Integer。将parseInt转换为以下方法，该方法在不可解析数据的情况下只返回默认值，而不会抛出异常:

  public static int parseUnsignedInt(String s, int defaultValue) {
    final int strLength = s.length();
    if (strLength == 0)
      return defaultValue;
    int value = 0;
    for (int i=strLength-1; i>=0; i--) {
      int c = s.charAt(i);
      if (c > 47 && c < 58) {
        c -= 48;
        for (int j=strLength-i; j!=1; j--)
          c *= 10;
        value += c;
      } else {
        return defaultValue;
      }
    }
    return value < 0 ? /* übergebener wert > Integer.MAX_VALUE? */ defaultValue : value;
  }

只要您将这两种方法应用于“有效”数据，它们将以大致相同的速率工作(即使Integer。parseInt设法处理更复杂的数据)。但是当您试图解析无效数据时(例如解析“abc”1.000.000次)，性能上的差异应该是至关重要的。

即使抛出异常并不慢，对于正常的程序流抛出异常仍然是一个坏主意。使用这种方式，它是类似于GOTO…

我想这并没有真正回答问题。我想抛出异常的“传统”智慧在早期的java版本(< 1.4)中是正确的。创建异常需要虚拟机创建整个堆栈跟踪。从那时起，在VM中发生了很多变化，以加快速度，这可能是已经改进的一个领域。

为什么异常回报率会比正常回报率慢呢?

只要不将堆栈跟踪输出到终端，将其保存到一个文件或类似的文件中，catch块就不会比其他代码块做更多的工作。所以，我无法想象为什么“throw new my_cool_error()”应该这么慢。

好问题，我期待关于这个话题的进一步信息!

关于异常性能的好文章是:

https://shipilev.net/blog/2014/exceptional-performance/

实例化vs重用现有的，有堆栈跟踪和没有，等等:

Benchmark                            Mode   Samples         Mean   Mean error  Units

dynamicException                     avgt        25     1901.196       14.572  ns/op
dynamicException_NoStack             avgt        25       67.029        0.212  ns/op
dynamicException_NoStack_UsedData    avgt        25       68.952        0.441  ns/op
dynamicException_NoStack_UsedStack   avgt        25      137.329        1.039  ns/op
dynamicException_UsedData            avgt        25     1900.770        9.359  ns/op
dynamicException_UsedStack           avgt        25    20033.658      118.600  ns/op

plain                                avgt        25        1.259        0.002  ns/op
staticException                      avgt        25        1.510        0.001  ns/op
staticException_NoStack              avgt        25        1.514        0.003  ns/op
staticException_NoStack_UsedData     avgt        25        4.185        0.015  ns/op
staticException_NoStack_UsedStack    avgt        25       19.110        0.051  ns/op
staticException_UsedData             avgt        25        4.159        0.007  ns/op
staticException_UsedStack            avgt        25       25.144        0.186  ns/op

根据堆栈跟踪的深度:

Benchmark        Mode   Samples         Mean   Mean error  Units

exception_0000   avgt        25     1959.068       30.783  ns/op
exception_0001   avgt        25     1945.958       12.104  ns/op
exception_0002   avgt        25     2063.575       47.708  ns/op
exception_0004   avgt        25     2211.882       29.417  ns/op
exception_0008   avgt        25     2472.729       57.336  ns/op
exception_0016   avgt        25     2950.847       29.863  ns/op
exception_0032   avgt        25     4416.548       50.340  ns/op
exception_0064   avgt        25     6845.140       40.114  ns/op
exception_0128   avgt        25    11774.758       54.299  ns/op
exception_0256   avgt        25    21617.526      101.379  ns/op
exception_0512   avgt        25    42780.434      144.594  ns/op
exception_1024   avgt        25    82839.358      291.434  ns/op

有关其他详细信息(包括来自JIT的x64汇编程序)，请阅读原始博客文章。

这意味着Hibernate/Spring/etc-EE-shit因为异常(xD)而变慢。

通过重写应用程序控制流，避免异常(返回错误作为返回)，提高应用程序的性能10 -100倍，这取决于你抛出它们的频率))

不幸的是，我的回答太长了，不能在这里发表。所以让我在这里总结一下，并向你推荐http://www.fuwjax.com/how-slow-are-java-exceptions/以获得更具体的细节。

这里真正的问题不是“与“从未失败的代码”相比，“将失败报告为异常”的速度有多慢?”，正如人们所接受的回答可能会让你相信的那样。相反，问题应该是“与其他方式报告的失败相比，‘作为异常报告的失败’有多慢?”通常，报告失败的另外两种方法是使用哨兵值或使用结果包装器。

哨兵值是在成功情况下返回一个类，在失败情况下返回另一个类的尝试。你几乎可以把它看作是返回一个异常而不是抛出一个异常。这需要一个与success对象共享的父类，然后执行“instanceof”检查和几个类型转换来获得成功或失败的信息。

事实证明，冒着类型安全的风险，Sentinel值比异常快，但仅快大约2倍。现在，这可能看起来很多，但2倍只包括实现差异的成本。实际上，这个因素要低得多，因为我们可能失败的方法要比本页其他地方示例代码中的几个算术运算符有趣得多。

另一方面，结果包装器根本不牺牲类型安全。它们将成功和失败信息包装在单个类中。因此，它们提供了一个“isSuccess()”来代替“instanceof”，并为成功和失败对象提供了getter。但是，结果对象大约比使用异常慢2倍。事实证明，每次创建一个新的包装器对象比有时抛出异常要昂贵得多。

最重要的是，异常是语言提供的一种指示方法可能失败的方式。没有其他方法可以仅从API判断哪些方法总是(大部分)工作，哪些方法报告失败。

异常比哨兵更安全，比结果对象更快，并且比两者都不那么令人惊讶。我并不是建议用try/catch替换if/else，但是异常是报告失败的正确方式，即使在业务逻辑中也是如此。

也就是说，我想指出的是，我遇到的两种最常见的实质上影响性能的方法是创建不必要的对象和嵌套循环。如果可以在创建异常和不创建异常之间选择，请不要创建异常。如果要在有时创建异常或始终创建另一个对象之间做出选择，那么就创建异常。