问: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编译器正确优化代码，从而降低代码的速度。我还没有测试过这个理论。
关于异常性能的好文章是:
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倍，这取决于你抛出它们的频率))
我对异常速度和以编程方式检查数据的看法。
许多类都有字符串到值的转换器(扫描器/解析器)，也有受人尊敬和知名的库;)
通常有形式
class Example {
public static Example Parse(String input) throws AnyRuntimeParsigException
...
}
异常名称只是例子，通常是未选中的(运行时)，所以抛出声明只是我的图片
有时存在第二种形式:
public static Example Parse(String input, Example defaultValue)
不扔
当第二个文件不可用时(或者程序员读的文档太少，只使用第一个文件)，用正则表达式编写这样的代码。正则表达式很酷，政治正确等:
Xxxxx.regex(".....pattern", src);
if(ImTotallySure)
{
Example v = Example.Parse(src);
}
使用这段代码，程序员没有异常成本。BUT具有相当高的代价的正则表达式ALWAYS与小的代价异常有时。
我几乎总是在这种情况下使用
try { parse } catch(ParsingException ) // concrete exception from javadoc
{
}
没有分析堆栈跟踪等，我相信在你的讲座后相当快。
不要害怕例外情况
我改变了上面的@Mecki的答案，让method1在调用方法中返回一个布尔值和一个检查，因为你不能用什么都不替换一个异常。在运行两次之后，method1仍然是最快的或者和method2一样快。
下面是代码的快照:
// Calculates without exception
public boolean method1(int i) {
value = ((value + i) / i) << 1;
// Will never be true
return ((i & 0xFFFFFFF) == 1000000000);
}
....
for (i = 1; i < 100000000; i++) {
if (t.method1(i)) {
System.out.println("Will never be true!");
}
}
和结果:
运行1
method1 took 841 ms, result was 2
method2 took 841 ms, result was 2
method3 took 85058 ms, result was 2
运行2
method1 took 821 ms, result was 2
method2 took 838 ms, result was 2
method3 took 85929 ms, result was 2
