这篇文章主要讲解了“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异常是不是对性能有影响这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
