try-catch會影響程序性能嗎 – JAVA編程語言程序開發技術文章

Try-Catch真的會影響程序性能嗎
今天和TL爭論try-catch使用上的問題,是否為瞭代碼看上去的美觀而把該方法下得所有代碼都放到try-catch中,我理所當然的持反對意見,但對try-catch的實現機制沒有深入研究過,不能說出有說服力的理由,今天在網上找到個.net的try-catch分析,和大傢分享下
    很多帖子都分析過Try-Catch的機制,以及其對性能的影響。
   但是並沒有證據證明,Try-Catch過於損耗瞭系統的性能,尤其是在托管環境下。記得園子裡有位網友使用StopWatch分析過Try-Catch在不同情況下,與無Try-Catch的代碼相比,代碼運行的時間指標,結果並沒有很大差異。
    下面我來結合IL分析一下Try-Catch吧。
    ● 機制分析
    .Net 中基本的異常捕獲與處理機制是由try…catch…finally塊來完成的,它們分別完成瞭異常的監測、捕獲與處理工作。一個try塊可以對應零個或多個catch塊,可以對應零個或一個finally塊。不過沒有catch的try似乎沒有什麼意義,如果try對應瞭多個catch,那麼監測到異常後,CLR會自上而下搜索catch塊的代碼,並通過異常過濾器篩選對應的異常,如果沒有找到,那麼CLR將沿著調用堆棧,向更高層搜索匹配的異常,如果已到堆棧頂部依然沒有找到對應的異常,就會拋出未處理的異常瞭,這時catch塊中的代碼並不會被執行。所以距離try最近的catch塊將最先被遍歷到。
    如有以下代碼:
    try
   {
       Convert.ToInt32("Try");
   }
       catch (FormatException ex1)
   {
       string CatchFormatException = "CatchFormatException";
   }
       catch (NullReferenceException ex2)
   {
       string CatchNullReferenceException = "CatchNullReferenceException";
   }
   finally
   {
       string Finally = "Finally";
   }
  對應IL如下:
.method private hidebysig instance void Form1_Load(object sender,
class [mscorlib]System.EventArgs e) cil managed
{
// Code size 53 (0x35)
.maxstack 1
.locals init ([0] class [mscorlib]System.FormatException ex1,
[1] string CatchFormatException,
[2] class [mscorlib]System.NullReferenceException ex2,
[3] string CatchNullReferenceException,
[4] string Finally)
IL_0000: nop
IL_0001: nop
IL_0002: ldstr "Try"
IL_0007: call int32 [mscorlib]System.Convert::ToInt32(string)
IL_000c: pop
IL_000d: nop
IL_000e: leave.s IL_0026
IL_0010: stloc.0
IL_0011: nop
IL_0012: ldstr "CatchFormatException"
IL_0017: stloc.1
IL_0018: nop
IL_0019: leave.s IL_0026
IL_001b: stloc.2
IL_001c: nop
IL_001d: ldstr "CatchNullReferenceException"
IL_0022: stloc.3
IL_0023: nop
IL_0024: leave.s IL_0026
IL_0026: nop
IL_0027: leave.s IL_0033
IL_0029: nop
IL_002a: ldstr "Finally"
IL_002f: stloc.s Finally
IL_0031: nop
IL_0032: endfinally
IL_0033: nop
IL_0034: ret
IL_0035:
// Exception count 3
.try IL_0001 to IL_0010 catch [mscorlib]System.FormatException handler IL_0010 to IL_001b
.try IL_0001 to IL_0010 catch [mscorlib]System.NullReferenceException handler IL_001b to IL_0026
.try IL_0001 to IL_0029 finally handler IL_0029 to IL_0033
} // end of method Form1::Form1_Load
    末尾的幾行代碼揭示出IL是怎樣處理異常處理的。最後三行的每一個Item被稱作Exception Handing Clause,EHC組成Exception Handing Table,EHT與正常代碼之間由ret返回指令隔開。
    可以看出,FormatException排列在EHT的第一位。
    當代碼成功執行或反之而返回後,CLR會遍歷EHT:
    1. 如果拋出異常, CLR會根據拋出異常的代碼的“地址”找到對應的EHC(IL_0001 to IL_0010為檢測代碼的范圍),這個例子中CLR將找到2條EHC, FormatException會最先被遍歷到,且為適合的EHC。
    2. 如果返回的代碼地址在IL_0001 to IL_0029內,那麼還會執行finally handler 即IL_0029 to IL_0033中的代碼,不管是否因成功執行代碼而返回。
    事實上,catch與finally的遍歷工作是分開進行的,如上文所言,CLR首先做的是遍歷catch,當找到合適的catch塊後,再遍歷與之對應finally;而且這個過程會遞歸進行至少兩次,因為編譯器將C#的try…catch…finally翻譯成IL中的兩層嵌套。
當然如果沒有找到對應的catch塊,那麼CLR會直接執行finally,然後立即中斷所有線程。Finally塊中的代碼肯定會被執行,無論try是否檢測到瞭異常。
    ● 改進建議
    由上面的內容可以得出:
    如果使用瞭“Try-Catch”,且捕獲到瞭異常,CLR做的隻不過是遍歷Exception Handing Table中的Catch項;然後再次遍歷Exception Handing Table中的Finally項,所用時間幾乎都花費在遍歷Exception Handing Table上;而如果沒有捕獲到異常,CLR隻是遍歷Exception Handing Table中的Finally項,所需時間微乎其微。
    而“Try-Catch”遍歷後的執行對應操作所用時間,則根據你的具體代碼所定,“Try-Catch”引起的隻是監控與觸發,不應將這部分的代碼時間也算“Try-Catch”的消耗。
    所以,可以從性能和代碼評審兩方面考慮,一般建議有以下幾點準則:
    1.盡量給CLR一個明確的異常信息,不要使用Exception去過濾異常
    2.盡量不要將try…catch寫在循環中
    3. try盡量少的代碼,如果有必要可以使用多個catch塊,並且將最有可能拋出的異常類型,書寫在距離try最近的位置
    4.不要隻聲明一個Exception對象,而不去處理它。這樣做白白增加瞭Exception Handing Table的長度。
    5.使用性能計數器實用工具的“CLR Exceptions”檢測異常情況,並適當優化
    6.使用成員的Try-Parse模式,如果拋出異常,那麼用false代替它
    結論,Try-Catch雖然會消費一點時間,但程序人員大可不必談虎色變,通過上面的分析,與其說“Try-Catch”會損耗或影響性能,不如說“Try-Catch”與其他代碼一樣,隻是性能的普通消費者,但出於代碼書寫評審方面的考慮,還是盡量關照一下“Try-Catch”吧。

 

本文出自“muzi666boy”
 

發佈留言