JAVA異常是不是對(duì)性能有影響

這篇文章主要講解了“JAVA異常是不是對(duì)性能有影響”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“JAVA異常是不是對(duì)性能有影響”吧！

實(shí)驗(yàn)

我的實(shí)驗(yàn)基于一段隨機(jī)拋出異常的簡(jiǎn)單代碼。從科學(xué)的角度，這并非完全準(zhǔn)確的測(cè)量，同時(shí)我也并不了解HotSpot 編譯器會(huì)對(duì)運(yùn)行中的代碼做何動(dòng)作。但無(wú)論如何，這段代碼應(yīng)該能夠讓我們了解一些基本情況。

結(jié)果很有意思：拋出與捕獲異常的代價(jià)似乎極低。在我的例子里，大約是每個(gè)異常 0.02 毫秒。除非你真的拋出太多異常（我們指的是 10 萬(wàn)次或者更多），否則這一點(diǎn)基本都可忽略。 盡管這些結(jié)果顯示出異常處理本身并不影響代碼性能，但卻并未解決下面這個(gè)問(wèn)題：異常對(duì)性能的巨大影響該由誰(shuí)負(fù)責(zé)？

我明顯遺漏了什么重要的問(wèn)題。

重新想了一下，我意識(shí)到自己遺漏了異常處理的一個(gè)重要部分。我沒(méi)考慮到異常發(fā)生時(shí)你做了什么。在多數(shù)情況下你很有可能不僅僅是捕獲異常！而問(wèn)題就在 這里：一般情況下，你會(huì)試圖對(duì)問(wèn)題進(jìn)行補(bǔ)充，并讓應(yīng)用在最終用戶那里仍能發(fā)揮功能。所以我遺漏的就是：“”為了處理異常而執(zhí)行的補(bǔ)充代碼“”。按照補(bǔ)充代 碼的不同，性能損失可能會(huì)變得相當(dāng)顯著。在某些情況下這可能意味著重試連接到服務(wù)器，在另一些情況下則可能意味著使用默認(rèn)的回滾方案，而這種方案提供的解 決辦法肯定會(huì)帶來(lái)非常差勁的性能。對(duì)于我們?cè)诤芏嗲闆r下看到的行為，這似乎給出了很好的解釋。

不過(guò)我卻不覺(jué)得分析到這里已經(jīng)萬(wàn)事大吉，而是感到這里還遺漏了別的什么東西。

Stack trace

對(duì)此問(wèn)題，我仍頗為好奇，為此監(jiān)視了收集 strack trace 時(shí)情況性能有何變化。

經(jīng)常發(fā)生的情況應(yīng)該是這樣的：記下異常及其棧軌跡，嘗試找出問(wèn)題到底在哪。

為此我修改了代碼，額外收集了異常的 strack trace 。這讓情況顯著改變。對(duì)異常的 strack trace 的收集，其性能影響要比單純捕獲并拋出異常高出10倍。因此盡管 strack trace 有助于理解哪里發(fā)生了問(wèn)題（有可能還有助于理解為何發(fā)生問(wèn)題），但卻存在性能損失。 由于我們談?wù)摰牟⒎且粭l strack trace，所以此處的影響往往非常之大。 多數(shù)情況下，我們都要在多個(gè)層次上拋出并捕獲異常。 我們看一個(gè)簡(jiǎn)單的例子： Web 服務(wù)客戶端連接到服務(wù)器。首先，Java 庫(kù)級(jí)別上存在一個(gè)連接失敗異常。此后會(huì)有框架級(jí)別上的客戶端失敗異常，再以后可能還會(huì)有應(yīng)用層次上的業(yè)務(wù)邏輯調(diào)用失敗異常。到現(xiàn)在為止，總共要搜集三條 strack trace。 多數(shù)情況下，你都能從日志文件或者應(yīng)用輸出中看到這些 strack trace，而寫入這些較長(zhǎng)的strack trace 往往也會(huì)也帶來(lái)性能影響。

感謝各位的閱讀，以上就是“JAVA異常是不是對(duì)性能有影響”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)JAVA異常是不是對(duì)性能有影響這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！