這篇文章主要介紹“JAVA異常對性能有什么影響”,在日常操作中,相信很多人在JAVA異常對性能有什么影響問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”JAVA異常對性能有什么影響”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
東麗網(wǎng)站制作公司哪家好,找創(chuàng)新互聯(lián)公司!從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站等網(wǎng)站項目制作,到程序開發(fā),運營維護。創(chuàng)新互聯(lián)公司公司2013年成立到現(xiàn)在10年的時間,我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗,來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。
在對OneAPM的客戶做技術(shù)支 持時,我們常常會看到很多客戶根本沒意識到的異常。在消除了這些異常之后,代碼運行速度與以前相比大幅提升。這讓我們產(chǎn)生一種猜測,就是在代碼里面使用異 常會帶來顯著的性能開銷。因為異常是錯誤情況處理的重要組成部分,摒棄是不太可能的,所以我們需要衡量異常處理對于性能影響,我們可以通過一個實驗看看異 常處理的對于性能的影響。
實驗
我的實驗基于一段隨機拋出異常的簡單代碼。從科學(xué)的角度,這并非完全準(zhǔn)確的測量,同時我也并不了解HotSpot
編譯器會對運行中的代碼做何動作。但無論如何,這段代碼應(yīng)該能夠讓我們了解一些基本情況。
結(jié)果很有意思:拋出與捕獲異常的代價似乎極低。在我的例子里,大約是每個異常 0.02 毫秒。除非你真的拋出太多異常(我們指的是 10 萬次或者更多),否則這一點基本都可忽略。 盡管這些結(jié)果顯示出異常處理本身并不影響代碼性能,但卻并未解決下面這個問題:異常對性能的巨大影響該由誰負責(zé)?
我明顯遺漏了什么重要的問題。
重新想了一下,我意識到自己遺漏了異常處理的一個重要部分。我沒考慮到異常發(fā)生時你做了什么。在多數(shù)情況下你很有可能不僅僅是捕獲異常!而問題就在 這里:一般情況下,你會試圖對問題進行補充,并讓應(yīng)用在最終用戶那里仍能發(fā)揮功能。所以我遺漏的就是:“”為了處理異常而執(zhí)行的補充代碼“”。按照補充代 碼的不同,性能損失可能會變得相當(dāng)顯著。在某些情況下這可能意味著重試連接到服務(wù)器,在另一些情況下則可能意味著使用默認(rèn)的回滾方案,而這種方案提供的解 決辦法肯定會帶來非常差勁的性能。對于我們在很多情況下看到的行為,這似乎給出了很好的解釋。
不過我卻不覺得分析到這里已經(jīng)萬事大吉,而是感到這里還遺漏了別的什么東西。
Stack trace
對此問題,我仍頗為好奇,為此監(jiān)視了收集 strack trace 時情況性能有何變化。
經(jīng)常發(fā)生的情況應(yīng)該是這樣的:記下異常及其棧軌跡,嘗試找出問題到底在哪。
為此我修改了代碼,額外收集了異常的 strack trace 。這讓情況顯著改變。對異常的 strack trace 的收集,其性能影響要比單純捕獲并拋出異常高出10倍。因此盡管 strack trace 有助于理解哪里發(fā)生了問題(有可能還有助于理解為何發(fā)生問題),但卻存在性能損失。 由于我們談?wù)摰牟⒎且粭l strack trace,所以此處的影響往往非常之大。 多數(shù)情況下,我們都要在多個層次上拋出并捕獲異常。 我們看一個簡單的例子: Web 服務(wù)客戶端連接到服務(wù)器。首先,Java 庫級別上存在一個連接失敗異常。此后會有框架級別上的客戶端失敗異常,再以后可能還會有應(yīng)用層次上的業(yè)務(wù)邏輯調(diào)用失敗異常。到現(xiàn)在為止,總共要搜集三條 strack trace。 多數(shù)情況下,你都能從日志文件或者應(yīng)用輸出中看到這些 strack trace
,而寫入這些較長的strack trace
往往也會也帶來性能影響。
到此,關(guān)于“JAVA異常對性能有什么影響”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
本文名稱:JAVA異常對性能有什么影響
分享路徑:http://weahome.cn/article/iiiipe.html