資訊專欄INFORMATION COLUMN
摘要：對異常的的收集，其性能影響要比單純捕獲并拋出異常高出倍。但我們應該對代碼中拋出的異常數量進行跟蹤，它們可能導致顯著的性能影響。
在對我們的客戶做技術支持時，我們常常會看到很多客戶根本沒意識到的異常。在消除了這些異常之后，代碼運行速度與以前相比大幅提升。這讓我們產生一種猜測，就是在代碼里面使用異常會帶來顯著的性能開銷。因為異常是錯誤情況處理的重要組成部分，摒棄是不太可能的,所以我們需要衡量異常處理對于性能影響，我們可以通過一個實驗看看異常處理的對于性能的影響。
實驗我的實驗基于一段隨機拋出異常的簡單代碼。從科學的角度，這并非完全準確的測量，同時我也并不了解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 往往也會也帶來性能影響。
結論首先因為存在性能影響而把異常棄之不用并非良策。異常有助于提供一種一致的方式來解決運行時問題，并且有助于寫出干凈的代碼。但我們應該對代碼中拋出的異常數量進行跟蹤，它們可能導致顯著的性能影響。所以我們默認要對所拋出的異常進行跟蹤——在很多情況下人們都會對代碼中發生的異常以及在解決這些異常時的性能損耗感到吃驚不已。 其次盡管使用異常很有裨益，您也應避免捕獲過多的 strack trace。異常應該是為異常的情況而設計的，使用時應該牢記這一原則。當然，萬一您不想遵從好的編程習慣，Java 語言就會讓您知道，那樣做可以讓您的程序運行得更快，從而鼓勵您去那樣做。
本文作者系 OneAPM 工程師陶炳哲。想閱讀更多技術文章，請訪問OneAPM 官方技術博客。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/65299.html
摘要：允許存在多個，用于針對不同的異常做不同的處理。表示程序可能需要捕獲并且處理的異常。因此，我們應該盡可能的避免通過異常來處理正常的邏輯檢查，這樣可以確保不會因為發生異常而導致性能問題。異常表中的每一條記錄，都代表了一個異常處理器。 showImg(https://segmentfault.com/img/remote/1460000017918154?w=640&h=100); show...
摘要：分析性能的影響但是需要注意時間單位，只是微秒而已，毫秒的千分之一秒的百萬分之一。在這種情況下，優化毫秒的性能隱患無異于撿了芝麻丟了西瓜。 同步自：https://sulin.me/2019/T2ZXZB.... 在分布式系統開發中，我們經常需要將各種各樣的狀態碼、錯誤信息傳遞給最外層的調用方，這個調用方通常是http/api接口，錯誤信息比如登錄失效、參數錯誤等等。 最外層接口暴露的...
摘要：聲明本文所有列舉的問題都來源于編程隨想的博客，這個博客的博主知識淵博，編程方面的一些文章質量很高，給人醍醐灌頂的感覺。 聲明：本文所有列舉的問題都來源于 《編程隨想》的博客，這個博客的博主知識淵博，編程方面的一些文章質量很高，給人醍醐灌頂的感覺。 算法和數據結構 什么時候該用數組類型容器，什么時候該用鏈表型容器，如何合理的使用數據類型 什么是散列函數,HashMap的實現原理是什么 ...
摘要：代碼優化的最重要的作用應該是避免未知的錯誤。此舉能夠使性能平均提高。拋出異常首先要創建一個新的對象，接口的構造函數調用名為的本地同步方法，方法檢查堆棧，收集調用跟蹤信息。異常只能用于錯誤處理，不應該用來控制程序流程。 showImg(https://segmentfault.com/img/remote/1460000015379073); 代碼優化的最重要的作用應該是：避免未知的錯誤...
摘要：此舉能夠使性能平均提高。盡可能使用局部變量調用方法時傳遞的參數以及在調用中創建的臨時變量都保存在棧中速度較快，其他變量，如靜態變量實例變量等，都在堆中創建，速度較慢。 showImg(https://segmentfault.com/img/bVbsIIl?w=900&h=383);本文來源 |?http://atjf.top/3WLPmG 作者 | 萌小Q 01前沿 代碼優化 ，一個...
閱讀 4093·2021-10-08 10:04
閱讀 3074·2021-08-11 11:20
閱讀 2748·2021-07-25 21:37
閱讀 2695·2019-08-30 12:44
閱讀 2324·2019-08-30 11:12
閱讀 1325·2019-08-26 13:45
閱讀 2374·2019-08-26 11:53
閱讀 3068·2019-08-26 11:32
