相关疑难解决方法(0)

问题:Java中的异常处理实际上是否很慢？

传统观念以及许多谷歌搜索结果表明,不应将特殊逻辑用于Java中的正常程序流程.通常有两个原因,

1. 它确实很慢 - 甚至比常规代码慢一个数量级(给出的原因各不相同),

和

2. 它很混乱,因为人们只希望在特殊代码中处理错误.

这个问题是关于#1.

例如,这个页面将Java异常处理描述为"非常慢",并将缓慢与异常消息字符串的创建联系起来 - "然后将此字符串用于创建抛出的异常对象.这并不快." Java中的有效异常处理这篇文章说"其原因在于异常处理的对象创建方面,从而使异常本身变得缓慢".另一个原因是堆栈跟踪生成减慢了它的速度.

我的测试(使用Java 1.6.0_07,Java HotSpot 10.0,在32位Linux上)表明异常处理并不比常规代码慢.我尝试在循环中运行一个执行一些代码的方法.在方法结束时,我使用布尔值来指示是返回还是抛出.这样实际处理是一样的.我尝试以不同的顺序运行方法并平均我的测试时间,认为它可能是JVM升温.在我的所有测试中,投掷至少与返回一样快,如果不是更快(最多快3.1%).我对我的测试错误的可能性持开放态度,但我没有看到代码示例,测试比较或过去一两年中显示Java中的异常处理的结果慢.

让我沿着这条路走下去的是我需要使用的API,它将异常作为正常控制逻辑的一部分.我想在他们的使用中纠正它们,但现在我可能无法做到.相反,我是否必须赞美他们的前瞻性思维？

在即时编译中的高效Java异常处理文章中,作者建议单独存在异常处理程序,即使没有抛出异常,也足以阻止JIT编译器正确优化代码,从而减慢它的速度.我还没有测试过这个理论.

我们知道捕获异常是昂贵的.但是,即使从未抛出异常,在Java中使用try-catch块也是昂贵的吗？

我发现Stack Overflow问题/答案为什么尝试块昂贵？,但它适用于.NET.

我不想讨论何时抛出异常而不抛出异常.我想解决一个简单的问题.99%的时间不抛出异常的论点围绕着它们缓慢而另一方声称(基准测试)速度不是问题.我读过很多关于一方或另一方的博客,文章和帖子.那是哪个呢？

答案中的一些链接:Skeet,Mariani,Brumme.

可能重复:
'尝试'的性能成本

我被告知,在一个百万的for循环的例子中,添加一个try catch块会增加大约1000倍的主要性能成本.这是真的？

是不是最好尽可能使用try catch块？

看起来捕获错误比在错误之前执行检查(例如TryParse)慢.提示观察的相关问题在这里和这里.

任何人都可以告诉我为什么会这样 - 为什么捕获错误以执行一次或多次数据检查以防止错误的成本更高？