我们来简单地分析一下上面的coding.
我们创建了一个继承自MarshalByRefObject,因为我需要让它具有跨AppDomain传递的能力。在这个Class中定义了两个为实现线程同步的helper字段,一个是string类型的_stringLockHelper和object类型的_objectLockHelper,并为他们定义了相应的Property。此外定义了两个方法:ExecuteWithStringLocked和ExecuteWithStringLocked,他们的操作类似:在先对_stringLockHelper和_objectLockHelper加锁的前提下,输出出操作执行的AppDomain和确切时间。我们通过调用Thread.Sleep模拟10s的时间延迟。
在Main方法中,首先创建了两个AppDomain,名称分别为Artech.AppDomain1和Artech.AppDomain2。随后在这两个AppDomain中创建两个MarshalByRefType对象,并为它们的StringLockHelper属性赋上相同的值:Hello World。最后,我们创建了两个新的线程,并在它们中分别调用在两个不同AppDomain 中创建的MarshalByRefType对象的ExecuteWithStringLocked方法。我们来看看运行后的输出结果:
从上面的输出结果中可以看出,两个分别在不同线程中执行操作对应的AppDomain的name分别为Artech.AppDomain1和Artech.AppDomain2。执行的时间(确切地说是操作成功地对MarshalByRefType对象的_stringLockHelper字段进行加锁的时间)相隔10s,也就是我们在程序中定义的时间延迟。
为什么会出现这样的结果呢?我们只是对两个处于不同AppDomain的不同的MarshalByRefType对象的stringLockHelper字段进行加锁。由于我们是同时开始他们对应的线程,照理说它们之间不会有什么关联,显示出来的时间应该是相同的。唯一的解释就是:虽然这两个在不同的AppDomain中创建的对象是两个完全不同的对象,由于他们的stringLockHelper字段具有相同的字符序列,它们引用的是同一个string。这就证明了我们提出的跨AppDomain进行string interning的结论。
为了进一步印证我们的结论,我们是使两个MarshalByRefObject对象的stringLockHelper字段具有不同的值,看看结果又如何。于是我们把其中一个对象的stringLockHelper字段改为”Hello World!”(多加了一个!) 。
看看现在的输出结果,现在的时间是一样了。
上面我们做的是对string类型字段加锁的试验。那么我们对其他类型的对象进行加锁,又会出现怎么的情况呢?我们现在就来做这样试验:在各自的线程中调用两个对象的ExecuteWithObjectLocked方法。我们修改Execute方法和Main()。
我们先来看看运行后的输出结果:
我们发现两个时间是一样的,那么就是说两个对象的ObjectLockHelper引用的不是同一个对象。虽然上面的程序很简单,我觉得里面涉及的规程却很值得一说。我们来分析下面3段代码。
简单看起来,两个MarshalByRefObject对象的ObjectLockHelper都是引用的同一个对象obj。但是背后的情况没有那么简单。代码第一行创建了一个新的对象obj,这个对象是在当前AppDomain 中创建的。二对于当前的AppDomain来说,marshalByRefObj1和marshalByRefObj2仅仅是一个Transparent proxy而已,它们包含一个在Artech.AppDomain1和Artech.AppDomain2中创立的MarshalByRefObject对象的引用。我们为它的ObjectLockHelper复制,对于Transparent proxy对象的赋值调用会传到真正对象所在的AppDomain,由于obj是当前AppDomain的对象,它不能直接赋给另一个AppDomain的对象。所以它必须经历一个Marshaling的过程才能被传递到另外一个AppDomain。实际上当复制操作完成之后,真正的ObjectLockHelper属性对应的对象是根据原数据重建的对象,和在当前AppDomain中的对象已经没有任何的关系。所以两个MarshalByRefObject对象的ObjectLockHelper属性引用的并不是同一个对象,所以对它进行加锁对彼此不要产生任何影响。
四、 从Garbage Collection的角度来看string
我们知道在一个托管的环境下,一个对象的生命周期被GC管理和控制。一个对象只有在他不被引用的时候,GC才会对他进行垃圾回收。而对于一个string来说,它始终被interning table引用,而这个interning table是针对一个Process的,是被该Process所有AppDomain共享的,所以一个string的生命周期相对比较长,只有所有的AppDomain都不具有对该string的引用时,他才有可能被垃圾回收。
五、 从多线程的角度来看string
一方面由于string的恒定性,我们不用考虑多线程的并发操作产生的线程同步问题。另一方面由于字符串的驻留,我们在对一个string对象进行加锁操作的时候,极有可能拖慢这个Application的performance,就像我们的Sample中演示的那样。而且很有可能影响到处于同一进程的其他Application,以致造成死锁。所以我们在使用锁的时候,除非万不得已,切忌对一个string进行加锁。
六、 如何高效地使用string
下面简单介绍一些高效地使用string的一些小的建议:
1. 尽量使用字符串(literal string)相加来代替字符串变量和字符创相加,因为这样可以使用现有的string操作指令进行操作和利用字符串驻留。
比如:
优于
2. 在需要的时候使用StringBuilder对string作频繁的操作:
由于string的恒定性,在我们对一个string进行某些操作的时候,比如调用ToUpper()或者ToLower()把某个string每个字符转化成大写或者小写;调用SubString()取子串;会创建一个新的string,有时候会创建一些新的临时string。这样的操作会增加内存的压力。所有在对string作频繁操作的情况下,我们会考虑使用StringBuilder来高效地操作string。StringBuilder之所以能对string操作带来更好的performance,是因为在它的内部维护一个字符数组,而不是一个string来避免string操作带来的新的string的创建。
StringBuilder是一个很好的字符累加器,我们应该充分地利用这一个功能:
最好写成
避免创建一个新的临时string来保存str1 + str2。
再比如下面的Code
最好写好吧WorkOnString1,WorkOnString2,WorkOnString3定义成:
3. 高效地进行string的比较操作
我们知道,对象之间的比较有比较Value和比较Reference之说。一般地对Reference进行比较的速度最快。对于string,在字符串驻留的前提下,我们可以把对Value的比较用Reference的比较来代替从而会的Performance的提升。
此外,对于忽略大小写的比较,我们最好使用string的static方法Compare(string strA, string strB, bool ignoreCase)。也就是说:
最好写成