string與StringBuilder的在字符串拼接時執行效率上有差異，因為StringBuilder類中用了一個技巧：它申請了兩倍的內存空間存放字符串，在調用Append方法拼接字符串時，會先檢查剩余的空間是否能放下要拼接的字符串，若能放下，則將要拼接的字符串Copy到剩余的空間中，若不能放下，則再申請拼接后的字符串兩倍的長度空間，將當前字符串Copy到新的空間中（除了兩倍的空間外，這點跟string的拼接沒有太多的差異）。因此StringBuilder能提高字符串拼接的效率在于它減少了申請分配內存的次數，以及字符串Copy的數量。所以這里就有了以下4種情況的討論：

1.原來的長字符串拼接短字符串。

這實際上就是最吻合StringBuilder申請多余空間的意圖，能夠達到最好的效果的一種情形。具體的情況是這樣的，假設一個StringBuilder存放的初始字符串長度為1000，那么實例化這個StringBuilder時，會申請2000的空間，隨后，每次拼接長度為20的字符串，則會直接將這長度為20的字符串按順序放在剩下的1000空間里，直到放滿為止，其間有50次的拼接操作，此時若再拼接一個長度為20的字符串時，因為空間不夠，這是StringBuilder會申請2000*2=4000的空間，然后將原先已拼接的長度2000的字符串Copy進去后，繼續拼接新的長度為20的字符串。這最后一步跟string操作的效率幾乎一樣的，主要是前面的50次拼接能減少50次的內存創建以及Copy全部字符串到新字符串的效率損耗。若是string進行拼接，則前50次拼接操作中，每次都會新分配一塊內存，并將現有的字符串全部Copy到新的內存中。

2. 原來的長字符串拼接長字符串。

這種情況在開始時會因為空間很快被用完，并不能體現StringBuilder在字符串拼接方面的優勢，但隨著拼接次數的增加，會轉換成第一種情況。

3.原來的短字符串拼接短字符串。

4.原來的短字符串拼接長字符串。

其實后面三種情況都要根據實際來評估了，最終都是要向情況一進行轉變。所以我們的關注點主要是被拼接的字符串與已有字符串之間長度的差距有多少，能減少多少次臨時內存分配來達到提高字符串拼接效率的目的的。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。

原文鏈接：http://www.cnsendblog.com/?p=86