由于使用 System.String 類會(huì)在某些場(chǎng)合帶來明顯的性能損耗，所以微軟另外提供了一個(gè)類型StringBuilder來彌補(bǔ)String的不足。

StringBuilder并不會(huì)重新創(chuàng)建一個(gè)string 對(duì)象，它的效率源于預(yù)先以非托管的方式分配內(nèi)存。如果StringBuilder 沒有先定義長度，則默認(rèn)分配的長度為16。當(dāng) StringBuilder 字符長度小于等于 16時(shí)，StringBuilder 不會(huì)重新分配內(nèi)存；當(dāng) StringBuilder 字符長度大于16 小于 32時(shí)，StringBuilder 又會(huì)重新分配內(nèi)存，使之成為 16的倍數(shù)。在上面的代碼中，如果預(yù)先判斷字符串的長度將大于16，則可以為其設(shè)定一個(gè)更加合適的長度（如32）。StringBuilder重新分配內(nèi)存時(shí)是按照上次的容量加倍進(jìn)行分配的。當(dāng)然，我們需要注意，StringBuilder指定的長度要合適，太小了，需要頻繁分配內(nèi)存；太大了，浪費(fèi)空間。

曾經(jīng)有人問我，下面的兩種字符串拼接方式，哪種效率更高：

1.      private static void NewMethod8()  
        {  
            string a = "t";  
            a += "e";  
            a += "s";  
            a += "t";  
        }  
 
2.      private static void NewMethod7()  
        {  
            string a = "t";  
            string b = "e";  
            string c = "s";  
            string d = "t";  
            string result = a + b + c + d;  
        } 

答案是：兩者效率都不高。不要以為前者比后者創(chuàng)建的字符串對(duì)象更少，事實(shí)上，兩者創(chuàng)建的字符串對(duì)象相等，且前者進(jìn)行了3次string.Contact方法調(diào)用，比后者還多了兩次。

要完成這樣的運(yùn)行時(shí)字符串拼接（注意：是運(yùn)行時(shí)），更佳的做法是使用StringBuilder類型，代碼如下所示：

private static void NewMethod10()  
{  
    //為了演示的需要，定義了4個(gè)變量  
    string a = "t";  
    string b = "e";  
    string c = "s";  
    string d = "t";  
    StringBuilder sb = new StringBuilder(a);  
    sb.Append(b);  
    sb.Append(c);  
    sb.Append(d);  
    //再次提示，是運(yùn)行時(shí)，所以沒有使用下面的代碼  
    //StringBuilder sb = new StringBuilder("t");  
    //sb.Append("e");  
    //sb.Append("s");  
    //sb.Append("t");  
    string result = sb.ToString();  
} 

微軟還提供了另外一個(gè)方法來簡(jiǎn)化這種操作，即使用string.Format方法。string.Format方法在內(nèi)部使用StringBuilder進(jìn)行字符串的格式化，如下面的代碼所示：

private static void NewMethod11()  
{  
    //為了演示的需要，定義了4個(gè)變量  
    string a = "t";  
    string b = "e";  
    string c = "s";  
    string d = "t";  
    string.Format("{0}{1}{2}{3}", a, b, c, d);  
}