快捷導(dǎo)航

C#中Try-Catch語句真的影響程序性能嗎？

更新時間：2015年06月05日 09:58:23 投稿：junjie

這篇文章主要介紹了C#中Try-Catch語句真的影響程序性能嗎？本文結(jié)合IL分析Try-Catch語句的性能問題,需要的朋友可以參考下

很多帖子都分析過Try-Catch的機制，以及其對性能的影響。

但是并沒有證據(jù)證明，Try-Catch過于損耗了系統(tǒng)的性能，尤其是在托管環(huán)境下。記得園子里有位網(wǎng)友使用StopWatch分析過Try-Catch在不同情況下，與無Try-Catch的代碼相比，代碼運行的時間指標(biāo)，結(jié)果并沒有很大差異。

下面我來結(jié)合IL分析一下Try-Catch吧。

● 機制分析

.Net 中基本的異常捕獲與處理機制是由try…catch…finally塊來完成的，它們分別完成了異常的監(jiān)測、捕獲與處理工作。一個try塊可以對應(yīng)零個或多個catch塊，可以對應(yīng)零個或一個finally塊。不過沒有catch的try似乎沒有什么意義，如果try對應(yīng)了多個catch，那么監(jiān)測到異常后，CLR會自上而下搜索catch塊的代碼，并通過異常過濾器篩選對應(yīng)的異常，如果沒有找到，那么CLR將沿著調(diào)用堆棧，向更高層搜索匹配的異常，如果已到堆棧頂部依然沒有找到對應(yīng)的異常，就會拋出未處理的異常了，這時catch塊中的代碼并不會被執(zhí)行。所以距離try最近的catch塊將最先被遍歷到。

如有以下代碼：

復(fù)制代碼代碼如下:

    try
   {
       Convert.ToInt32("Try");
   }
       catch (FormatException ex1)
   {

       string CatchFormatException = "CatchFormatException";
   }
       catch (NullReferenceException ex2)
   {

string CatchNullReferenceException = "CatchNullReferenceException";
}

   finally
   {
       string Finally = "Finally";
   }

對應(yīng)IL如下：

復(fù)制代碼代碼如下:

.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返回指令隔開。

可以看出，F(xiàn)ormatException排列在EHT的第一位。

當(dāng)代碼成功執(zhí)行或反之而返回后，CLR會遍歷EHT：

1. 如果拋出異常， CLR會根據(jù)拋出異常的代碼的“地址”找到對應(yīng)的EHC（IL_0001 to IL_0010為檢測代碼的范圍），這個例子中CLR將找到2條EHC，F(xiàn)ormatException會最先被遍歷到，且為適合的EHC。

2. 如果返回的代碼地址在IL_0001 to IL_0029內(nèi)，那么還會執(zhí)行finally handler 即IL_0029 to IL_0033中的代碼，不管是否因成功執(zhí)行代碼而返回。

事實上，catch與finally的遍歷工作是分開進行的，如上文所言，CLR首先做的是遍歷catch，當(dāng)找到合適的catch塊后，再遍歷與之對應(yīng)finally；而且這個過程會遞歸進行至少兩次，因為編譯器將C#的try…catch…finally翻譯成IL中的兩層嵌套。

當(dāng)然如果沒有找到對應(yīng)的catch塊，那么CLR會直接執(zhí)行finally，然后立即中斷所有線程。Finally塊中的代碼肯定會被執(zhí)行，無論try是否檢測到了異常。

改進建議

由上面的內(nèi)容可以得出：

如果使用了“Try-Catch”，且捕獲到了異常，CLR做的只不過是遍歷Exception Handing Table中的Catch項；然后再次遍歷Exception Handing Table中的Finally項，所用時間幾乎都花費在遍歷Exception Handing Table上；而如果沒有捕獲到異常，CLR只是遍歷Exception Handing Table中的Finally項，所需時間微乎其微。

而“Try-Catch”遍歷后的執(zhí)行對應(yīng)操作所用時間，則根據(jù)你的具體代碼所定，“Try-Catch”引起的只是監(jiān)控與觸發(fā)，不應(yīng)將這部分的代碼時間也算“Try-Catch”的消耗。

所以，可以從性能和代碼評審兩方面考慮，一般建議有以下幾點準(zhǔn)則：

1.盡量給CLR一個明確的異常信息，不要使用Exception去過濾異常

2.盡量不要將try…catch寫在循環(huán)中

3. try盡量少的代碼，如果有必要可以使用多個catch塊，并且將最有可能拋出的異常類型，書寫在距離try最近的位置

4.不要只聲明一個Exception對象，而不去處理它。這樣做白白增加了Exception Handing Table的長度。

5.使用性能計數(shù)器實用工具的“CLR Exceptions”檢測異常情況，并適當(dāng)優(yōu)化

6.使用成員的Try-Parse模式，如果拋出異常，那么用false代替它

結(jié)論，Try-Catch雖然會消費一點時間，但程序人員大可不必談虎色變，通過上面的分析，與其說“Try-Catch”會損耗或影響性能，不如說“Try-Catch”與其他代碼一樣，只是性能的普通消費者，但出于代碼書寫評審方面的考慮，還是盡量關(guān)照一下“Try-Catch”吧。

您可能感興趣的文章: