鑽石舞台

文章來源：https://blog.csdn.net/bokerr/article/details/122655795

目錄

一、JVM 異常處理邏輯

二、關於JVM的編譯優化

三、關於測試的約束

四、測試代碼

五、解釋模式下執行測試

六、編譯模式測試

七、結論

前言

不知道從何時起，傳出了這麼一句話：Java中使用try catch 會嚴重影響性能。

然而，事實真的如此麼？我們對try catch 應該畏之如猛虎麼？

Java 程序中顯式拋出異常由athrow指令支持，除了通過 throw 主動拋出異常外，JVM規範中還規定了許多運行時異常會在檢測到異常狀況時自動拋出(效果等同athrow), 例如除數為0時就會自動拋出異常，以及大名鼎鼎的 NullPointerException 。

還需要注意的是，JVM 中 異常處理的catch語句不再由字節碼指令來實現(很早之前通過 jsr和 ret指令來完成，它們在很早之前的版本里就被捨棄了)，現在的JVM通過異常表(Exception table 方法體中能找到其內容)來完成 catch 語句；很多人說try catch 影響性能可能就是因為認識還停留於上古時代。

1、我們編寫如下的類，add 方法中計算 ++x; 並捕獲異常。

2、使用javap 工具查看上述類的編譯後的class文件

忽略常量池等其他信息，下邊貼出add 方法編譯後的 機器指令集：

再來看 Exception table：

from=0， to=5。指令 0~5 對應的就是 try 語句包含的內容，而targer = 8 正好對應 catch 語句塊內部操作。

個人理解，from 和 to 相當於劃分區間，只要在這個區間內拋出了type 所對應的，「java/lang/Exception」 異常(主動athrow 或者 由jvm運行時檢測到異常自動拋出)，那麼就跳轉到target 所代表的第八行。

若執行過程中，沒有異常，直接從第5條指令跳轉到第11條指令後返回，由此可見未發生異常時，所謂的性能損耗幾乎不存在；

如果硬是要說的話，用了try catch 編譯後指令篇幅變長了；goto 語句跳轉會耗費性能，當你寫個數百行代碼的方法的時候，編譯出來成百上千條指令，這時候這句goto的帶來的影響顯得微乎其微。

如圖所示為去掉try catch 後的指令篇幅，幾乎等同上述指令的前五條。

綜上所述：「Java中使用try catch 會嚴重影響性能」 是民間說法，它並不成立。如果不信，接着看下面的測試吧。

其實寫出測試用例並不是很難，這裡我們需要重點考慮的是編譯器的自動優化，是否會因此得到不同的測試結果？

本節會粗略的介紹一些jvm編譯器相關的概念，講它只為更精確的測試結果，通過它我們可以窺探 try catch 是否會影響JVM的編譯優化。

前端編譯與優化：我們最常見的前端編譯器是 javac，它的優化更偏向於代碼結構上的優化，它主要是為了提高程序員的編碼效率，不怎麼關注執行效率優化；例如，數據流和控制流分析、解語法糖等等。

後端編譯與優化：後端編譯包括 「即時編譯[JIT]」 和 「提前編譯[AOT]」，區別於前端編譯器，它們最終作用體現於運行期，致力於優化從字節碼生成本地機器碼的過程(它們優化的是代碼的執行效率)。

PS * JVM 自己根據宿主機決定自己的運行模式, 「JVM 運行模式」；[客戶端模式-Client、服務端模式-Server]，它們代表的是兩個不同的即時編譯器，C1(Client Compiler) 和 C2 (Server Compiler)。

PS * 分層編譯分為：「解釋模式」、「編譯模式」、「混合模式」；

解釋模式下運行時，編譯器不介入工作；

編譯模式模式下運行，會使用即時編譯器優化熱點代碼，有可選的即時編譯器[C1 或 C2]；

混合模式為：解釋模式和編譯模式搭配使用。

如圖，我的環境裡JVM 運行於 Server 模式，如果使用即時編譯，那麼就是使用的：C2 即時編譯器。

了解如下的幾個 概念：

（1）解釋模式

它不使用即時編譯器進行後端優化

強制虛擬機運行於 「解釋模式」 -Xint

禁用後台編譯 -XX:-BackgroundCompilation

（2）編譯模式

即時編譯器會在運行時，對生成的本地機器碼進行優化，其中重點關照熱點代碼。

所謂 「即時」，它是在運行過程中發生的，所以它的缺點也也明顯：在運行期間需要耗費資源去做性能分析，也不太適合在運行期間去大刀闊斧的去做一些耗費資源的重負載優化操作。

它是後端編譯的另一個主角，它有兩個發展路線，基於Graal [新時代的主角] 編譯器開發，因為本文用的是 C2 編譯器，所以只對它做一個了解；

第一條路線：與傳統的C、C++編譯做的事情類似，在程序運行之前就把程序代碼編譯成機器碼；好處是夠快，不占用運行時系統資源，缺點是"啟動過程" 會很緩慢；

第二條路線：已知即時編譯運行時做性能統計分析占用資源，那麼，我們可以把其中一些耗費資源的編譯工作，放到提前編譯階段來完成啊，最後在運行時即時編譯器再去使用，那麼可以大大節省即時編譯的開銷；這個分支可以把它看作是即時編譯緩存；

遺憾的是它只支持 G1 或者 Parallel 垃圾收集器，且只存在JDK 9 以後的版本，暫不需要去關注它；JDK 9 以後的版本可以使用這個參數打印相關信息：[-XX:PrintAOT]。

System.naoTime() 輸出的是過了多少時間[微秒：10的負9次方秒]，並不是完全精確的方法執行用時的合計，為了保證結果準確性，測試的運算次數將拉長到百萬甚至千萬次。

這裡我要做的是：對比完全不使用任何編譯優化，與使用即時編譯時，try catch 對的性能影響。

（1）通過指令禁用 JVM 的編譯優化，讓它以最原始的狀態運行，然後看有無 try catch 的影響。

（2）通過指令使用即時編譯，儘量做到把後端優化拉滿，看看 try catch 十有會影響到 jvm的編譯優化。

目前尚未可知 try catch 的使用影響指令重排序；

我們這裡的討論有一個前提，當 try catch 的使用無法避免時，我們應該如何使用 try catch 以應對它可能存在的對指令重排序的影響。

指令重排序發生在多線程並發場景，這麼做是為了更好的利用CPU資源，在單線程測試時不需要考慮。不論如何指令重排序，都會保證最終執行結果，與單線程下的執行結果相同；

雖然我們不去測試它，但是也可以進行一些推斷，參考 volatile 關鍵字禁止指令重排序的做法：插入內存屏障；

假定 try catch 存在屏障，導致前後的代碼分割；那麼最少的try catch代表最少的分割。

所以，是不是會有這樣的結論呢：我們把方法體內的 多個 try catch 合併為一個 try catch 是不是反而能減少屏障呢？這麼做勢必造成 try catch 的範圍變大。

當然，上述關於指令重排序討論內容都是基於個人的猜想，猶未可知 try catch 是否影響指令重排序；本文重點討論的也只是單線程環境下的 try catch 使用影響性能。

循環次數為100W ，循環內10次預算[給編譯器優化預留優化的可能，這些指令可能被合併]；

每個方法都會到達千萬次浮點計算。

同樣每個方法外層再循環跑多次，最後取其中的眾數更有說服力。

設置如下JVM參數，禁用編譯優化

結合測試代碼發現，即使百萬次循環計算，每個循環內都使用了 try catch 也並沒用對造成很大的影響。

唯一發現了一個問題，每個循環內都是使用 try catch 且使用多次。發現性能下降，千萬次計算差值為：5~7 毫秒；4個 try 那麼執行的指令最少4條goto ，前邊闡述過，這裡造成這個差異的主要原因是 goto 指令占比過大，放大了問題；當我們在幾百行代碼里使用少量try catch 時，goto所占比重就會很低，測試結果會更趨於合理。

設置如下測試參數，執行10 次即為熱點代碼

執行結果如下圖，難分勝負，波動只在微秒級別，執行速度也快了很多，編譯效果拔群啊，甚至連 「解釋模式」 運行時多個try catch 導致的，多個goto跳轉帶來的問題都給順帶優化了；由此也可以得到 try catch 並不會影響即時編譯的結論。

我們可以再上升到億級計算，依舊難分勝負，波動在毫秒級。

try catch 不會造成巨大的性能影響，換句話說，我們平時寫代碼最優先考慮的是程序的健壯性，當然大佬們肯定都知道了怎麼合理使用try catch了，但是對萌新來說，你如果不確定，那麼你可以使用 try catch；

在未發生異常時，給代碼外部包上 try catch，並不會造成影響。

舉個栗子吧，我的代碼中使用了：URLDecoder.decode，所以必須得捕獲異常。

調用方法百萬次，執行結果如下：

經過這個例子，我想你知道你該如何 編寫你的代碼了吧？可怕的不是 try catch 而是 搬磚業務不熟練啊。