“你看著這鬼代碼,竟然在 for 循環(huán)里面搞了個(gè) try-catch,不知道try-catch有性能損耗嗎?”
老陳煞有其事地指著屏幕里的代碼:
for(inti=0;i5000;?i++)?{ ?????try?{ ?????????dosth ?????}?catch?(Exception?e)?{ ?????????e.printStackTrace(); ?????} ?}
我探過頭去看了眼代碼,“那老陳你覺得該怎么改?”
“當(dāng)然是把 try-catch 提到外面??!”老陳腦子都不轉(zhuǎn)一下,脫口而出。
“你是不是傻?且不說性能,這代碼的目的明顯是讓循環(huán)內(nèi)部單次調(diào)用出錯(cuò)不影響循環(huán)的運(yùn)行,你其到外面業(yè)務(wù)邏輯不就變了嗎!”
老陳撓了撓他的地中海,“好像也是啊!”
“回過頭來,catch 整個(gè) for 循環(huán)和在循環(huán)內(nèi)部 catch,在不出錯(cuò)的情況下,其實(shí)性能差不多?!?我喝一口咖啡不經(jīng)意地提到,準(zhǔn)備在老陳前面秀一下。
“啥意思?”老陳有點(diǎn)懵地看著我,“try-catch是有性能損耗的,我可是看過網(wǎng)上資料的!”
果然,老陳上鉤了,我二話不說直接打開 idea,一頓操作敲了以下代碼:
publicclassTryCatchTest{ @Benchmark publicvoidtryfor(Blackholeblackhole){ try{ for(inti=0;i5000;?i++)?{ ????????????????blackhole.consume(i); ????????????} ????????}?catch?(Exception?e)?{ ????????????e.printStackTrace(); ????????} ????} ????@Benchmark ????public?void?fortry(Blackhole?blackhole)?{ ????????for?(int?i?=?0;?i?5000;?i++)?{ ????????????try?{ ????????????????blackhole.consume(i); ????????????}?catch?(Exception?e)?{ ????????????????e.printStackTrace(); ????????????} ????????} ????} }
“BB 不如 show code,看到?jīng)],老陳,我把 try-catch 從 for 循環(huán)里面提出來跟在for循環(huán)里面做個(gè)對比跑一下,你猜猜兩個(gè)差多少?”
“切,肯定 tryfor 性能好,想都不用想,不是的話我倒立洗頭!”老陳信誓旦旦道。
我懶得跟他BB,直接開始了 benchmark,跑的結(jié)果如下:
可以看到,兩者的性能(數(shù)字越大越好)其實(shí)差不多:
fortry: 86,261(100359-14098) ~ 114,457(100359+14098)
tryfor: 95,961(103216-7255) ~ 110,471(103216+7255)
我再調(diào)小(一般業(yè)務(wù)場景 for 循環(huán)次數(shù)都不會(huì)很多)下 for 循環(huán)的次數(shù)為 1000 ,結(jié)果也是差不多:
老陳一看傻了:“說好的性能影響呢?怎么沒了?”
我直接一個(gè)javap,讓老陳看看,其實(shí)兩個(gè)實(shí)現(xiàn)在字節(jié)碼層面沒啥區(qū)別:
tryfor 的字節(jié)碼
異常表記錄的是 0 - 20 行,如果這些行里面的代碼出現(xiàn)問題,直接跳到 23 行處理。
fortry 的字節(jié)碼
差別也就是異常表的范圍小點(diǎn),包的是 9-14 行,其它跟 tryfor 都差不多。
圖片
所以從字節(jié)碼層面來看,沒拋錯(cuò)兩者的執(zhí)行效率其實(shí)沒啥差別。
“那為什么網(wǎng)上流傳著try-catch會(huì)有性能問題的說法???”老陳覺得非常奇怪。
這個(gè)說法確實(shí)有,在《Effective Java》這本書里就提到了 try-catch 性能問題:
并且還有下面一段話:
圖片
正所謂聽話不能聽一半,以前讀書時(shí)候最怕的就是一知半解,因?yàn)橥耆斫膺x擇題能選對,完全不懂蒙可能蒙對,一知半解必定選到錯(cuò)誤的選項(xiàng)!
《Effective Java》書中說的其實(shí)是不要用 try-catch 來代替正常的代碼,書中的舉例了正常的 for 循環(huán)肯定這樣實(shí)現(xiàn):
但有個(gè)臥龍偏偏不這樣實(shí)現(xiàn),要通過 try-catch 拐著彎來實(shí)現(xiàn)循環(huán):
這操作我只能說有點(diǎn)逆天,這兩個(gè)實(shí)現(xiàn)的對比就有性能損耗了。
我們直接再跑下有try-catch 的代碼和沒 try-catch的 for 循環(huán)區(qū)別,代碼如下:
結(jié)果如下:
+-差不多,直接看前面的分?jǐn)?shù)對比,沒有 ry-catch 的性能確實(shí)好些,這也和書中說的 try-catch 會(huì)影響 JVM 一些特定的優(yōu)化說法吻合,但是具體沒有說影響哪些優(yōu)化,我猜測可能是指令重排之類的。
好了,我再總結(jié)下有關(guān) try-catch 性能問題說法:
try-catch 相比較沒 try-catch,確實(shí)有一定的性能影響,但是旨在不推薦我們用 try-catch 來代替正常能不用 try-catch 的實(shí)現(xiàn),而不是不讓用 try-catch。
for循環(huán)內(nèi)用 try-catch 和用 try-catch 包裹整個(gè) for 循環(huán)性能差不多,但是其實(shí)兩者本質(zhì)上是業(yè)務(wù)處理方式的不同,跟性能扯不上關(guān)系,關(guān)鍵看你的業(yè)務(wù)流程處理。
雖然知道try-catch會(huì)有性能影響,但是業(yè)務(wù)上不需要避諱其使用,業(yè)務(wù)實(shí)現(xiàn)優(yōu)先(只要不是書中舉例的那種逆天代碼就行),非特殊情況下性能都是其次,有意識地避免大范圍的try-catch,只 catch 需要的部分即可(沒把握全 catch 也行,代碼安全執(zhí)行第一)。
審核編輯:劉清
-
JAVA
+關(guān)注
關(guān)注
19文章
2947瀏覽量
104374 -
JVM
+關(guān)注
關(guān)注
0文章
157瀏覽量
12188
原文標(biāo)題:支付寶二面:使用 try-catch 捕獲異常會(huì)影響性能嗎?大部分人都會(huì)答錯(cuò)!
文章出處:【微信號:小林coding,微信公眾號:小林coding】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論