如果有理解错误的地方希望有朋友能指出，谢谢！

 

String是特殊的引用类型的，更像值类型，StringBuilder的是规规矩矩引用类型的。

 

首先看这样的对比图，Equals()方法是判断两个变量里面的值是否相等。

 

下面上代码和注释：

 

我们通过即时窗口直接获取他们所在的地址是什么？

其中我们发现引用类型sbA和sbB的地址是不一样的，所以通过比较运算符“==”得出的结果是false，而Equals比较值他们的值是“sss”，所以是true。

 

这里我们发现了一种情况，sA的地址竟然和sB的地址一样，还需要提及一个字符串拘留池的概念，具体概念百度。

我们继续探索，首先我们来看下这三个的地址：

s1和s2都是字符串“哈哈哈”，他们的栈地址也就是一样的，百度过字符串拘留池概念的人应该就明白了

下面我们来看一下传说中s4的地址：

我将是s1和s2拼接后返回给s4后，它的地址是：

 

然后再做一次操作：

得到s4的地址变化为：

 

既然拼接之后那我们之前的字符串还在吗？

 

事实说明s1还是存在的，那我们再换个方式测试一下

第一张图：

 

第二张图：

 

你会发现，重新申明的s5的地址竟然也是0x0224b310，应该是微软的垃圾回收没有执行，垃圾回收机制继续百度。

那我们手动的清理一遍，加上代码GC.Collect()：

 

是不是有点X炸天的感觉，为什么不会被GC？

那我多执行GC几次：

 

看吧！别天真了，我觉得事实已经验证出来了。

没察觉需要注意的地方？那我们试试引用类型？

第一张图：

 

第二张图：

 

s1和s3是不是被顺利回收掉了。

 

字符串拘留池：如果将同一个字符串赋值给不同的字符串引用，那么系统会为多次分配内存空间，然而这些内存中存储的是同一个字符串。这不仅浪费了宝贵的内存，还极大程度的降低了系统的性能。为了改善程序的性能，.net提出了字符串拘留池机制来解决这一问题。一旦使用了字符串拘留池，当CLR启动的时候，会在内部创建一个容器，容器的键是字符串内容，值时字符串在托管堆上的引用。当一个新的字符串对象需要分配时，CLR首先检测容器中是否包含了该字符串对象，如果已经包含，就直接返回已经存在的字符串对象的引用；如果不存在，则新分配一个字符串对象，并把它添加到内部容器中同时返回该字符串对象的引用。但是当用new关键字显示的申明分配一个字符串对象时，字符串拘留池机制不会再起作用。（这个概念是百度来的）

 

我的结论：我们在执行大量字符串拼接的时候，尽量使用StringBuilder去处理，如果使用string类型，每一次拼接都会产生一个冗余字段且不能被回收，虽然看起来不多，但是我觉得这是需要注意的地方。尤其看到同事依然选择string去拼接一大串的SQL语句，是有一点弊端的，如果一个系统长期在运行，产生的冗余字段将是不可估量的！

 

本文仅供参考，如果我理解有误，希望有朋友能告知，谢谢！

 

扩展：至于刚才写代码为什么用“{0}”这样用参数的形式来去替换，而不是使用string拼接，或者使用StringBuilder，我也反编译了一下看了，底层还是通过StringBuilder下面的AppendFormat来实现的，再往下就是微软的高深动作了，不继续探索了，微软的优化稳妥妥！