摘要:對(duì)異常的的收集,其性能影響要比單純捕獲并拋出異常高出倍。但我們應(yīng)該對(duì)代碼中拋出的異常數(shù)量進(jìn)行跟蹤,它們可能導(dǎo)致顯著的性能影響。
在對(duì)我們的客戶做技術(shù)支持時(shí),我們常常會(huì)看到很多客戶根本沒(méi)意識(shí)到的異常。在消除了這些異常之后,代碼運(yùn)行速度與以前相比大幅提升。這讓我們產(chǎn)生一種猜測(cè),就是在代碼里面使用異常會(huì)帶來(lái)顯著的性能開(kāi)銷。因?yàn)楫惓J清e(cuò)誤情況處理的重要組成部分,摒棄是不太可能的,所以我們需要衡量異常處理對(duì)于性能影響,我們可以通過(guò)一個(gè)實(shí)驗(yàn)看看異常處理的對(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ǔ)充,并讓?xiě)?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,而寫(xiě)入這些較長(zhǎng)的strack trace 往往也會(huì)也帶來(lái)性能影響。
結(jié)論首先因?yàn)榇嬖谛阅苡绊懚旬惓壷挥貌⒎橇疾?。異常有助于提供一種一致的方式來(lái)解決運(yùn)行時(shí)問(wèn)題,并且有助于寫(xiě)出干凈的代碼。但我們應(yīng)該對(duì)代碼中拋出的異常數(shù)量進(jìn)行跟蹤,它們可能導(dǎo)致顯著的性能影響。所以我們默認(rèn)要對(duì)所拋出的異常進(jìn)行跟蹤——在很多情況下人們都會(huì)對(duì)代碼中發(fā)生的異常以及在解決這些異常時(shí)的性能損耗感到吃驚不已。 其次盡管使用異常很有裨益,您也應(yīng)避免捕獲過(guò)多的 strack trace。異常應(yīng)該是為異常的情況而設(shè)計(jì)的,使用時(shí)應(yīng)該牢記這一原則。當(dāng)然,萬(wàn)一您不想遵從好的編程習(xí)慣,Java 語(yǔ)言就會(huì)讓您知道,那樣做可以讓您的程序運(yùn)行得更快,從而鼓勵(lì)您去那樣做。
本文作者系 OneAPM 工程師陶炳哲。想閱讀更多技術(shù)文章,請(qǐng)?jiān)L問(wèn)OneAPM 官方技術(shù)博客。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/65299.html
摘要:允許存在多個(gè),用于針對(duì)不同的異常做不同的處理。表示程序可能需要捕獲并且處理的異常。因此,我們應(yīng)該盡可能的避免通過(guò)異常來(lái)處理正常的邏輯檢查,這樣可以確保不會(huì)因?yàn)榘l(fā)生異常而導(dǎo)致性能問(wèn)題。異常表中的每一條記錄,都代表了一個(gè)異常處理器。 showImg(https://segmentfault.com/img/remote/1460000017918154?w=640&h=100); show...
摘要:分析性能的影響但是需要注意時(shí)間單位,只是微秒而已,毫秒的千分之一秒的百萬(wàn)分之一。在這種情況下,優(yōu)化毫秒的性能隱患無(wú)異于撿了芝麻丟了西瓜。 同步自:https://sulin.me/2019/T2ZXZB.... 在分布式系統(tǒng)開(kāi)發(fā)中,我們經(jīng)常需要將各種各樣的狀態(tài)碼、錯(cuò)誤信息傳遞給最外層的調(diào)用方,這個(gè)調(diào)用方通常是http/api接口,錯(cuò)誤信息比如登錄失效、參數(shù)錯(cuò)誤等等。 最外層接口暴露的...
摘要:聲明本文所有列舉的問(wèn)題都來(lái)源于編程隨想的博客,這個(gè)博客的博主知識(shí)淵博,編程方面的一些文章質(zhì)量很高,給人醍醐灌頂?shù)母杏X(jué)。 聲明:本文所有列舉的問(wèn)題都來(lái)源于 《編程隨想》的博客,這個(gè)博客的博主知識(shí)淵博,編程方面的一些文章質(zhì)量很高,給人醍醐灌頂?shù)母杏X(jué)。 算法和數(shù)據(jù)結(jié)構(gòu) 什么時(shí)候該用數(shù)組類型容器,什么時(shí)候該用鏈表型容器,如何合理的使用數(shù)據(jù)類型 什么是散列函數(shù),HashMap的實(shí)現(xiàn)原理是什么 ...
摘要:代碼優(yōu)化的最重要的作用應(yīng)該是避免未知的錯(cuò)誤。此舉能夠使性能平均提高。拋出異常首先要?jiǎng)?chuàng)建一個(gè)新的對(duì)象,接口的構(gòu)造函數(shù)調(diào)用名為的本地同步方法,方法檢查堆棧,收集調(diào)用跟蹤信息。異常只能用于錯(cuò)誤處理,不應(yīng)該用來(lái)控制程序流程。 showImg(https://segmentfault.com/img/remote/1460000015379073); 代碼優(yōu)化的最重要的作用應(yīng)該是:避免未知的錯(cuò)誤...
摘要:此舉能夠使性能平均提高。盡可能使用局部變量調(diào)用方法時(shí)傳遞的參數(shù)以及在調(diào)用中創(chuàng)建的臨時(shí)變量都保存在棧中速度較快,其他變量,如靜態(tài)變量實(shí)例變量等,都在堆中創(chuàng)建,速度較慢。 showImg(https://segmentfault.com/img/bVbsIIl?w=900&h=383);本文來(lái)源 |?http://atjf.top/3WLPmG 作者 | 萌小Q 01前沿 代碼優(yōu)化 ,一個(gè)...
閱讀 4092·2021-10-08 10:04
閱讀 3073·2021-08-11 11:20
閱讀 2745·2021-07-25 21:37
閱讀 2695·2019-08-30 12:44
閱讀 2321·2019-08-30 11:12
閱讀 1323·2019-08-26 13:45
閱讀 2373·2019-08-26 11:53
閱讀 3068·2019-08-26 11:32