十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要讲解了“JAVA异常是不是对性能有影响”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“JAVA异常是不是对性能有影响”吧!
超过十年行业经验,技术领先,服务至上的经营模式,全靠网络和口碑获得客户,为自己降低成本,也就是为客户降低成本。到目前业务范围包括了:网站设计制作、网站设计,成都网站推广,成都网站优化,整体网络托管,微信小程序,微信开发,成都app软件开发,同时也可以让客户的网站和网络营销和我们一样获得订单和生意!
实验
我的实验基于一段随机抛出异常的简单代码。从科学的角度,这并非完全准确的测量,同时我也并不了解HotSpot
编译器会对运行中的代码做何动作。但无论如何,这段代码应该能够让我们了解一些基本情况。
结果很有意思:抛出与捕获异常的代价似乎极低。在我的例子里,大约是每个异常 0.02 毫秒。除非你真的抛出太多异常(我们指的是 10 万次或者更多),否则这一点基本都可忽略。 尽管这些结果显示出异常处理本身并不影响代码性能,但却并未解决下面这个问题:异常对性能的巨大影响该由谁负责?
我明显遗漏了什么重要的问题。
重新想了一下,我意识到自己遗漏了异常处理的一个重要部分。我没考虑到异常发生时你做了什么。在多数情况下你很有可能不仅仅是捕获异常!而问题就在 这里:一般情况下,你会试图对问题进行补充,并让应用在最终用户那里仍能发挥功能。所以我遗漏的就是:“”为了处理异常而执行的补充代码“”。按照补充代 码的不同,性能损失可能会变得相当显著。在某些情况下这可能意味着重试连接到服务器,在另一些情况下则可能意味着使用默认的回滚方案,而这种方案提供的解 决办法肯定会带来非常差劲的性能。对于我们在很多情况下看到的行为,这似乎给出了很好的解释。
不过我却不觉得分析到这里已经万事大吉,而是感到这里还遗漏了别的什么东西。
Stack trace
对此问题,我仍颇为好奇,为此监视了收集 strack trace 时情况性能有何变化。
经常发生的情况应该是这样的:记下异常及其栈轨迹,尝试找出问题到底在哪。
为此我修改了代码,额外收集了异常的 strack trace 。这让情况显著改变。对异常的 strack trace 的收集,其性能影响要比单纯捕获并抛出异常高出10倍。因此尽管 strack trace 有助于理解哪里发生了问题(有可能还有助于理解为何发生问题),但却存在性能损失。 由于我们谈论的并非一条 strack trace,所以此处的影响往往非常之大。 多数情况下,我们都要在多个层次上抛出并捕获异常。 我们看一个简单的例子: Web 服务客户端连接到服务器。首先,Java 库级别上存在一个连接失败异常。此后会有框架级别上的客户端失败异常,再以后可能还会有应用层次上的业务逻辑调用失败异常。到现在为止,总共要搜集三条 strack trace。 多数情况下,你都能从日志文件或者应用输出中看到这些 strack trace
,而写入这些较长的strack trace
往往也会也带来性能影响。
感谢各位的阅读,以上就是“JAVA异常是不是对性能有影响”的内容了,经过本文的学习后,相信大家对JAVA异常是不是对性能有影响这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!