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.原来的短字符串拼接长字符串。
其实后面三种情况都要根据实际来评估了，最终都是要向情况一进行转变。所以我们的关注点主要是被拼接的字符串与已有字符串之间长度的差距有多少，能减少多少次临时内存分配来达到提高字符串拼接效率的目的的。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
