本文只是个人总结见解,勿喷
首先肯定的是string是引用类型
string s_a = "yhc";
string s_b = s_a;
if(s_a.Equals(s_b))
Console.WriteLine("相同?");
else
Console.WriteLine("不相同");
输出是“相同”,让s_b=s_a,本质是让s_b指向了yhc在堆上的存储位置,此时s_a和s_b都指向了yhc在堆上的存储位置。
理论上说如果修改s_a的值,例如s_a=”wq”,b也会跟着变化,但是实际上不是的,在c#里面,如果修改其中一个string对象的值比如s_a,系统会为s_a再重新申请一块内存用来存放修改后的s_a的值wq,而b依然指向于a曾今的内存位置。
这就是为什么在如果要频繁对string操作的时候建议用stringbuilder,因为stringbuilder类似c++中的标准库string,是可以动态增加内存大小的,而c#中的string是固定大小,你string一个对象就给你分配一个固定大小的内存空间,这个对象一旦创建就无法更改,如果你要往里面增加内容,我就必须新建一个string对象,把值拷贝进来,然后把之前的string对象删除,频繁操作string会带来效率的降低,毕竟创建对象,分配内存,删除对象这个过程需要耗时耗资源。
我们可以通过比较内存地址来断定这一结论(ReferenceEquals静态方法用于比较对象的引用是否一致,而不是简单的值),如果s_a和s_b指向的是同一地址,这里的比较应该返回相同
s_a =
"wq";
if (ReferenceEquals(s_a,s_b))
Console.WriteLine("相同");
else
Console.WriteLine("不相同");
答案很明显,会输出“不相同”,这说明系统为s_a重新分配了新地址的内存空间,当然你也许会说为什么不用==,因为string的= =被重写后,其实比较的还是string的值,(当然如果你一定要用= =也是可以的,只不过需要装箱成object类型,让==不再为string的特例重写比较,即if(((object)s_a)==( (object)s_b))),但是= =在比较其他对象的时候可不是这样了,这是string这个引用类型表现出值类型特征的一点,其实还有一个地方也表现了string类型的值类型特征表现,就是在string类型作为参数传递的时候,传递的是string对象的引用地址,但是在传递过去的方法里面修改string对象的值却不影响本体,这是因为系统根据传送过来的地址重新构造分配了一个全新的string对象,比如调用方法 void fun(string a);并把s_a传递作为参数过来的时候,a会被系统重新分配一个地址,而不是指向s_a的地址,这是引用类型的一个特例。比如A是一个普通类,比如
A b=new A();
b.name=”yhc”;
fun(b);
//代码运行到此,如果输出,此时输出a的name值:为wq
void fun(A a)
{
//代码运行到此,如果输出,此时输出a的name值:为yhc
a.name=”wq”;//因为参数传递的是b的引用,对a的操作就是对b的操作
//代码运行到此,如果输出,此时输出a的name值:为wq
}
但是如果是这样:
A b=new A();
b.name=”yhc”;
fun(b);
//代码运行到此,如果输出,此时输出a的name值:为yhc
void fun(A a)
{
//代码运行到此,如果输出,此时输出a的name值:为yhc
a=new A();
a.name=”wq”;
//代码运行到此,如果输出,此时输出a的name值:为wq
}
在执行玩fun(b)后的输出,就不再是wq了,因为在方法fun内部,我们把a指向了一个新建立在堆上的对象A,这个new对象在离开函数方法后会被GC垃圾回收机制回收,什么时候来回收就不知道了,当然如果是建立在堆栈上的资源会被立刻释放,但是关于建立在堆上的对象的GC回收也有特例,就是那些非托管对象,比如什么SqlConnection数据库连接、文件句柄、网络连接什么的,这些对象在方法内部new后,离开方法后不会被GC回收。
上面说的跑远里,我们回到之前,当然有人会说用ReferenceEquals来比较不够深刻和准确性,因为s_a改为wq后,值也发生了变化,用ReferenceEquals比较无法判断是值不同还是引用不同,于是我们如下修改:按照string修改后系统会自动为其分配新的内存空间的原理我们把s_a修改成yhc,即虽然修改了,但是值还是保持原来的yhc,只为了测试这个修改操作有没有重新分配内存空间
s_a = "yhc";
if (ReferenceEquals(s_a,s_b))
Console.WriteLine("相同");
else
Console.WriteLine("不相同");
我们都以为输出会是“不相同”,但是,但是结果让我们失望,系统输出“相同”,原因是微软的CLR使用了优化技术,叫做字符串驻留技术,这个技术的原理大家可能都知道,就是CLR初始化的时候会创建一个内部散列表,表为键值形式,键为字符串,比如这里的yhc,值为yhc在堆内存上存储的地址,初始化的时候散列表肯定为空了,即时编译器(JIT)编译时先去散列表找字符串yhc,第一次找没找到yhc,其就会在堆上开辟空间来存放yhc,然后把存放的地址和yhc这个字符串存储在散列表中,然后第二次又去找,就是这里的修改s_a的值为yhc,发现在散列表的键中找到了yhc这个值,于是就不再分配内存来存放修改后的yhc,而是让s_a依然指向之前这个yhc在堆上存放的空间,到此也就是说,你修改后的s_a=“yhc”,虽然修改了,但是其值没有变,还是yhc,所以被编译器的优化机制优化了,所以这个测试还是测试不出来我们要的效果。
上面测试缺陷的原理我们知道了,但是我们差点忘了我们到底是要测试什么,我们要测试的是s_a或者s_b修改后,系统为其重新分配内存空间,我们要比较修改后两者的空间地址是否一致,于是总结上面教训如下操作:
s_a=string.Copy(s_b)
if (ReferenceEquals(s_a,s_b))
Console.WriteLine("相同");
else
Console.WriteLine("不相同");
这里,s_a=string.Copy(s_b),string.Copy方法是创建一个与指定的s_b具有相同值的 System.String 的新实例。注意是新实例,用这个方法则编译器不会做上面的字符串驻留技术优化,即此时s_a再次被修改了,修改的值是拷贝了s_b的的值(s_b的值为yhc),即此时s_a的值也是yhc,这时候系统输出“不相同”了,这就验证了我们string对象被修改后,系统会为他重新分配内存空间。
完整测试代码如下:
测试很简单,但是深究很多
string s_a = "yhc";
string s_b = s_a;
s_a = string.Copy(s_b);
if (ReferenceEquals(s_a,s_b))
Console.WriteLine("相同");
else
Console.WriteLine("不相同");
Console.Read();