问:Java中的异常处理真的很慢吗?
传统观点以及大量谷歌结果表明，不应该将异常逻辑用于Java中的正常程序流。通常会给出两个原因，
它真的很慢——甚至比普通代码慢一个数量级(给出的原因各不相同)，
and
它很混乱，因为人们只希望在异常代码中处理错误。
这个问题是关于第一条的。
As an example, this page describes Java exception handling as "very slow" and relates the slowness to the creation of the exception message string - "this string is then used in creating the exception object that is thrown. This is not fast." The article Effective Exception Handling in Java says that "the reason for this is due to the object creation aspect of exception handling, which thereby makes throwing exceptions inherently slow". Another reason out there is that the stack trace generation is what slows it down.
My testing (using Java 1.6.0_07, Java HotSpot 10.0, on 32 bit Linux), indicates that exception handling is no slower than regular code. I tried running a method in a loop that executes some code. At the end of the method, I use a boolean to indicate whether to return or throw. This way the actual processing is the same. I tried running the methods in different orders and averaging my test times, thinking it may have been the JVM warming up. In all my tests, the throw was at least as fast as the return, if not faster (up to 3.1% faster). I am completely open to the possibility that my tests were wrong, but I haven't seen anything out there in the way of the code sample, test comparisons, or results in the last year or two that show exception handling in Java to actually be slow.
引导我走上这条路的是我需要使用的一个API，它将抛出异常作为正常控制逻辑的一部分。我想纠正它们的用法，但现在我可能做不到。我是否应该赞美他们的前瞻思维?
在论文《即时编译中的高效Java异常处理》中，作者建议，即使没有抛出异常，仅异常处理程序的存在就足以阻止JIT编译器正确优化代码，从而降低代码的速度。我还没有测试过这个理论。
供你参考，我扩展了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中，抛出异常的大部分开销是收集堆栈跟踪所花费的时间，这发生在创建异常对象时。抛出异常的实际成本虽然很大，但比创建异常的成本要小得多。
不幸的是，我的回答太长了，不能在这里发表。所以让我在这里总结一下，并向你推荐http://www.fuwjax.com/how-slow-are-java-exceptions/以获得更具体的细节。
这里真正的问题不是“与“从未失败的代码”相比，“将失败报告为异常”的速度有多慢?”，正如人们所接受的回答可能会让你相信的那样。相反，问题应该是“与其他方式报告的失败相比，‘作为异常报告的失败’有多慢?”通常，报告失败的另外两种方法是使用哨兵值或使用结果包装器。
哨兵值是在成功情况下返回一个类，在失败情况下返回另一个类的尝试。你几乎可以把它看作是返回一个异常而不是抛出一个异常。这需要一个与success对象共享的父类，然后执行“instanceof”检查和几个类型转换来获得成功或失败的信息。
事实证明，冒着类型安全的风险，Sentinel值比异常快，但仅快大约2倍。现在，这可能看起来很多，但2倍只包括实现差异的成本。实际上，这个因素要低得多，因为我们可能失败的方法要比本页其他地方示例代码中的几个算术运算符有趣得多。
另一方面，结果包装器根本不牺牲类型安全。它们将成功和失败信息包装在单个类中。因此，它们提供了一个“isSuccess()”来代替“instanceof”，并为成功和失败对象提供了getter。但是，结果对象大约比使用异常慢2倍。事实证明，每次创建一个新的包装器对象比有时抛出异常要昂贵得多。
最重要的是，异常是语言提供的一种指示方法可能失败的方式。没有其他方法可以仅从API判断哪些方法总是(大部分)工作，哪些方法报告失败。
异常比哨兵更安全，比结果对象更快，并且比两者都不那么令人惊讶。我并不是建议用try/catch替换if/else，但是异常是报告失败的正确方式，即使在业务逻辑中也是如此。
也就是说，我想指出的是，我遇到的两种最常见的实质上影响性能的方法是创建不必要的对象和嵌套循环。如果可以在创建异常和不创建异常之间选择，请不要创建异常。如果要在有时创建异常或始终创建另一个对象之间做出选择，那么就创建异常。
供你参考，我扩展了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中，抛出异常的大部分开销是收集堆栈跟踪所花费的时间，这发生在创建异常对象时。抛出异常的实际成本虽然很大，但比创建异常的成本要小得多。
关于异常性能的好文章是:
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倍，这取决于你抛出它们的频率))
