“你看著這鬼代碼，竟然在 for 循環里面搞了個 try-catch，不知道try-catch有性能損耗嗎？”

老陳煞有其事地指著屏幕里的代碼：

for(inti=0;i

	

	我探過頭去看了眼代碼，“那老陳你覺得該怎么改？”

	“當然是把 try-catch 提到外面啊！”老陳腦子都不轉一下，脫口而出。

	“你是不是傻？且不說性能，這代碼的目的明顯是讓循環內部單次調用出錯不影響循環的運行，你其到外面業務邏輯不就變了嗎！”

	老陳撓了撓他的地中海，“好像也是啊！”

	“回過頭來，catch 整個 for 循環和在循環內部 catch，在不出錯的情況下，其實性能差不多。” 我喝一口咖啡不經意地提到，準備在老陳前面秀一下。

	“啥意思？”老陳有點懵地看著我，“try-catch是有性能損耗的，我可是看過網上資料的！”

	果然，老陳上鉤了，我二話不說直接打開 idea，一頓操作敲了以下代碼：

	
publicclassTryCatchTest{

@Benchmark
publicvoidtryfor(Blackholeblackhole){
try{
for(inti=0;i

	

	“BB 不如 show code，看到沒，老陳，我把 try-catch 從 for 循環里面提出來跟在for循環里面做個對比跑一下，你猜猜兩個差多少？”

	“切，肯定 tryfor 性能好，想都不用想，不是的話我倒立洗頭！”老陳信誓旦旦道。

	我懶得跟他BB，直接開始了 benchmark，跑的結果如下：

	

	可以看到，兩者的性能（數字越大越好）其實差不多：

	fortry: 86,261(100359-14098) ~ 114,457(100359+14098)

	tryfor: 95,961(103216-7255) ~ 110,471(103216+7255)

	我再調小(一般業務場景 for 循環次數都不會很多)下 for 循環的次數為 1000 ，結果也是差不多：

	

	老陳一看傻了：“說好的性能影響呢？怎么沒了？”

	我直接一個javap，讓老陳看看，其實兩個實現在字節碼層面沒啥區別：

	tryfor 的字節碼

	異常表記錄的是 0 - 20 行，如果這些行里面的代碼出現問題，直接跳到 23 行處理。

	

	fortry 的字節碼

	差別也就是異常表的范圍小點，包的是 9-14 行，其它跟 tryfor 都差不多。

	圖片

	所以從字節碼層面來看，沒拋錯兩者的執行效率其實沒啥差別。

	“那為什么網上流傳著try-catch會有性能問題的說法啊？”老陳覺得非常奇怪。

	這個說法確實有，在《Effective Java》這本書里就提到了 try-catch 性能問題：

	

	并且還有下面一段話：

	圖片

	正所謂聽話不能聽一半，以前讀書時候最怕的就是一知半解，因為完全理解選擇題能選對，完全不懂蒙可能蒙對，一知半解必定選到錯誤的選項！

	《Effective Java》書中說的其實是不要用 try-catch 來代替正常的代碼，書中的舉例了正常的 for 循環肯定這樣實現：

	

	但有個臥龍偏偏不這樣實現，要通過 try-catch 拐著彎來實現循環：

	

	這操作我只能說有點逆天，這兩個實現的對比就有性能損耗了。

	我們直接再跑下有try-catch 的代碼和沒 try-catch的 for 循環區別，代碼如下：

	

	結果如下：

	

	+-差不多，直接看前面的分數對比，沒有 ry-catch 的性能確實好些，這也和書中說的 try-catch 會影響 JVM 一些特定的優化說法吻合，但是具體沒有說影響哪些優化，我猜測可能是指令重排之類的。

	好了，我再總結下有關 try-catch 性能問題說法：

	try-catch 相比較沒 try-catch，確實有一定的性能影響，但是旨在不推薦我們用 try-catch 來代替正常能不用 try-catch 的實現，而不是不讓用 try-catch。

	for循環內用 try-catch 和用 try-catch 包裹整個 for 循環性能差不多，但是其實兩者本質上是業務處理方式的不同，跟性能扯不上關系，關鍵看你的業務流程處理。

	雖然知道try-catch會有性能影響，但是業務上不需要避諱其使用，業務實現優先（只要不是書中舉例的那種逆天代碼就行），非特殊情況下性能都是其次，有意識地避免大范圍的try-catch，只 catch 需要的部分即可（沒把握全 catch 也行，代碼安全執行第一）。

	





	審核編輯：劉清