深入理解string

港控/mmm° 2022-03-27 11:52 293阅读 0赞

# [字符串的驻留（String Interning）][String Interning] #

关于字符串的驻留的机制，对于那些了解它的人肯定会认为很简单，但是我相信会有很大一部分人对它存在迷惑。在开始关于字符串的驻留之前，先给出一个有趣的Sample：

Code Snip：

![None.gif][] static  void  Main( string \[\] args)  
![ExpandedBlockStart.gif][] \{  
![InBlock.gif][]string str1 ="ABCD1234";  
![InBlock.gif][]string str2 ="ABCD1234";  
![InBlock.gif][]string str3 ="ABCD";  
![InBlock.gif][]string str4 ="1234";  
![InBlock.gif][]string str5 ="ABCD"\+"1234";  
![InBlock.gif][]string str6 ="ABCD"\+ str4;  
![InBlock.gif][]string str7 = str3 \+ str4;  
![InBlock.gif][]  
![InBlock.gif][] Console.WriteLine("string str1 = \\"ABCD1234\\";");  
![InBlock.gif][] Console.WriteLine("string str2 = \\"ABCD1234\\";");  
![InBlock.gif][] Console.WriteLine("string str3 = \\"ABCD\\";");  
![InBlock.gif][] Console.WriteLine("string str4 = \\"1234\\";");  
![InBlock.gif][] Console.WriteLine("string str5 = \\"ABCD\\" \+ \\"1234\\";");  
![InBlock.gif][] Console.WriteLine("string str6 = \\"ABCD\\" \+ str4;");  
![InBlock.gif][] Console.WriteLine("string str7 = str3 + str4;");  
![InBlock.gif][]  
![InBlock.gif][] Console.WriteLine("\\nobject.ReferenceEquals(str1, str2) = \{0\}", object.ReferenceEquals(str1, str2));  
![InBlock.gif][] Console.WriteLine("object.ReferenceEquals(str1, \\"ABCD1234\\") = \{0\}", object.ReferenceEquals(str1, "ABCD1234"));  
![InBlock.gif][]  
![InBlock.gif][] Console.WriteLine("\\nobject.ReferenceEquals(str1, str5) = \{0\}", object.ReferenceEquals(str1, str5));  
![InBlock.gif][] Console.WriteLine("object.ReferenceEquals(str1, str6) = \{0\}", object.ReferenceEquals(str1, str6));  
![InBlock.gif][] Console.WriteLine("object.ReferenceEquals(str1, str7) = \{0\}", object.ReferenceEquals(str1, str7));  
![InBlock.gif][]  
![InBlock.gif][] Console.WriteLine("\\nobject.ReferenceEquals(str1, string.Intern(str6)) = \{0\}", object.ReferenceEquals(str1, string.Intern(str6)));  
![InBlock.gif][] Console.WriteLine("object.ReferenceEquals(str1, string.Intern(str7)) = \{0\}", object.ReferenceEquals(str1, string.Intern(str7)));  
![ExpandedBlockEnd.gif][] \}   
![None.gif][]

下边是输出的结果：

![string_interning_01.jpg][]  
接下来我们来逐句地分析这段代码：

首先我们创建了两个完全相同的字符串（ABCD1234），并将他们分别赋予了两个字符创变量——str1和str2。然后把它们传给了object.ReferenceEquals。我们知道object.ReferenceEquals是用于确定两个变量是否具有相同的引用——换句话说，当两个变量引用的是同一块托管推的内存快的时候，返回True，否则返回False。

![None.gif][] string  str1  =  " ABCD1234 " ;  
![None.gif][] string  str2  =  " ABCD1234 " ;  
![None.gif][] object .ReferenceEquals(str1, str2) =  True；  
![None.gif][] object .ReferenceEquals(str1,  " ABCD1234 " ))  =  True;  
![None.gif][]

令我们感到奇怪的是，当我们分别创建的引用类型两个变量——string是引用类型。照理说CLR会在托管堆（Managed Heap）中为它们分配两段内存快，他们不可能具有相同的引用才对，但是为什么object.ReferenceEquals 方法会返回True呢。而对于第二个比较——一个字符串变量和一个和他具有相同内容的字符串（"ABCD1234";）直接进行比较，按照我们对CLR内存的分配的一般理解，应该是CLR首先会在托管堆中为这段字符串（"ABCD1234"）分配内存快，然后把相对应的引用传递给object.ReferenceEquals方法（由于分配在托管堆的这段字符串并没有被任何变量引用，所以当垃圾回收的时候会被回收掉），所以无论如何也不应该返回True。

我们先把问题留到最后，接着分析我们的Sample。上面们对字符串变量之间以及变量与字符串之间进行了比较，如果我们对一个字符串变量和一个动态创建的字符串（通过+Operator把两个字符串连接起来）进行比较，结果又会如何呢？我们来看看下面的伪代码演示：

![None.gif][] string  str3  =  " ABCD " ;  
![None.gif][] string  str4  =  " 1234 " ;  
![None.gif][] string  str5  =  " ABCD "  \+  " 1234 " ;  
![None.gif][] string  str6  =  " ABCD "  \+  str4;  
![None.gif][] string  str7  =  str3  \+  str4;  
![None.gif][] object .ReferenceEquals(str1, str5)  =  True  
![None.gif][] object .ReferenceEquals(str1, str6)  =  False  
![None.gif][] object .ReferenceEquals(str1, str7))  =  False  
![None.gif][]

在上面的例子中，我们用三种不同的方式创建了3个字符串变量（str5，str6，str7）——string+string；string+variable；variable+variable。然后分别和我们已经创建的、和它们具有相同字符串“值”的变量（str1）作比较。同样令我们感到奇怪的是第一个返回True，而后两个则为False。带着这些疑惑我们来看看对于string这一特殊的类型说采用的特殊的使用机制。

1． System.String虽然是一个引用类型，但是它具有其自身的特殊性。我们最容易想到的是它创建的特殊性——一般的对象在创建的时候需要通过**new**关键字调用对应的构造函数来实现；而创建一段string不需要这么做——我们只需要把对应的字符换赋给给对应的字符串变量就可以了。之所以存在着这种差异，是因为他们在创建过程中使用的IL指令时不同的——一般的引用对象的创建是通过**newobj**这样一个IL指令来实现的，而创建一个字符串变量的IL指令则是**ldstr** （load string）。（象C\#，VB.NET这样的语言毕竟是高级语言，进行了高度的抽象，站在这样的角度分析问题往往不能够看到其实质，所以有时候我们把应该从交底层上面找突破口——比如分析IL，Metadata…）;

2． 由于String是我们做到频率最高的一种类型，CLR考虑性能的提升和内存节约上，对于相同的字符串，一般不会为他们分别分配内存块，相反地，他们会共享一块内存。CLR实际上采用这个的机制来实现的：CLR内部维护着一块特殊的数据结构——我们可以把它看成是一个Hash table，这个Hash table维护者大部分创建的string（我这里没有说全部，因为有特例）。这个Hash table的Key对应的相应的string本身，而Value则是分配给这个string的内存块的引用。当CLR初始化的时候创建这个Hash table。一般地，在程序运行过程中，如果需要的创建一个string，CLR会根据这个string的Hash Code试着在Hash table中找这个相同的string，如果找到，则直接把找到的string的地址赋给相应的变量，如果没有则在托管堆中创建一个string，CLR会先在managed heap中创建该strng，并在Hash table中创建一个Key-Value Pair——Key为这个string本身，Value位这个新创建的string的内存地址，这个地址最重被赋给响应的变量。这样我们就能解释上面的疑问了。

当创建str1的时候，CLR现在我们上面提到的Hash table中找“ABCD1234”这样的一个string，没有找到，则在托管堆中为这个string分配一块内存，然后在Hash table为该string添加一个Key-Value Pair。接着创建str2，CLR仍然会在Hash table找ABCD1234这样的一个string，这回它会找到我们新创建的这个Entry，所以这个Key-Value Pair中Value（string的地址）会赋给str2。因为str1和str2 具有相同的引用，所以调用object.ReferenceEquals返回True。同理当我们对str1和"ABCD1234"进行比较的时候，str1直接传入该方法，放传入"ABCD1234"这个字符串的时候，CLR同样会在Hash table找ABCD1234这样的一个string，相同的Entry被找到，这个Entry（Key-Value Pair）的Value（string的地址）被传到object.ReferenceEquals，所以他们仍然相同的引用，结果返回True。

3． 并非所有的情况下字符串的驻留都会起作用。对于对一个动态创建的字符串（比如string+variable；variable+variable），这种驻留机制便不会起作用。因为对于这样的字符串，是不会被添加到内部的Hash table中的。但是对于string+string则不同，因为当这样的语句被编译成IL的时候，编译器是先把结构计算出来，然后再调用ldstr指令——而对于string+variable；variable+variable这种情况，所对应的IL指令是Concat。所以对于string+string字符串的驻留仍然有效。

比如对于以下一段代码：

![None.gif][]  static  void  Main( string \[\] args)  
![ExpandedBlockStart.gif][] \{  
![InBlock.gif][]string str1 ="ABC";  
![InBlock.gif][]string str2 = str1 \+"123";  
![InBlock.gif][]string str3 ="ABC"\+"123";  
![ExpandedBlockEnd.gif][]\}   
![None.gif][]

对应的IL Code是：

![None.gif][] .method  private  hidebysig  static  void  Main( string \[\] args) cil managed  
![ExpandedBlockStart.gif][] \{  
![InBlock.gif][] .entrypoint  
![InBlock.gif][]// Code size 26 (0x1a)  
![InBlock.gif][] .maxstack 2  
![InBlock.gif][] .locals init (\[0\] string str1,  
![InBlock.gif][] \[1\] string str2,  
![InBlock.gif][] \[2\] string str3)  
![InBlock.gif][] IL\_0000: nop  
![InBlock.gif][] IL\_0001: ldstr "ABC"  
![InBlock.gif][] IL\_0006: stloc.0  
![InBlock.gif][] IL\_0007: ldloc.0  
![InBlock.gif][] IL\_0008: ldstr "123"  
![InBlock.gif][] IL\_000d: call string \[mscorlib\]System.String::Concat(string,  
![InBlock.gif][]string)  
![InBlock.gif][] IL\_0012: stloc.1  
![InBlock.gif][] IL\_0013: ldstr "ABC123"  
![InBlock.gif][] IL\_0018: stloc.2  
![InBlock.gif][] IL\_0019: ret  
![ExpandedBlockEnd.gif][]\}  //  end of method Program::Main  
![None.gif][]

所以现在我们就可以解释第二个疑问了。

虽然对于对一个动态创建的字符串（比如string+variable；variable+variable），驻留机制便不会起作用。但是我们可以手工的启用驻留机制——那就是调用定义的System.String中的静态方法Intern。这个方法接受一个字符串作为他的输入参数，返回的经过驻留处理的string。他的实现机制是：如果能在内部的Hash Table中找到传入的string，则返回对应的string引用，否则就在Hash Table添加该string对应的Entry，并返回string的引用。所以下面的代码就不难解释了。

![None.gif][]  Console.WriteLine( " \\nobject.ReferenceEquals(str1, string.Intern(str6)) = \{0\} " ,  object .ReferenceEquals(str1,  string .Intern(str6)));  
![None.gif][] Console.WriteLine( " object.ReferenceEquals(str1, string.Intern(str7)) = \{0\} " ,  object .ReferenceEquals(str1,  string .Intern(str7)));  
![None.gif][]

相关内容：  
[\[原创\]如何改Managed Code的Performance和Scalability系列之二：深入理解string和如何高效地使用string][Managed Code_Performance_Scalability_string_string]

作者： [Artech][]  
出处： [http://artech.cnblogs.com/][Artech]  
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

# [深入理解string和如何高效地使用string][Managed Code_Performance_Scalability_string_string] #

无论你所使用的是哪种编程语言，我们都不得不承认这样一个共识：string是我们使用最为频繁的一种对象。但是string的常用性并不意味着它的简单性，而且我认为，正是由于string的频繁使用才会促使其设计人员在string的设计上花大量的功夫。所以正是这种你天天见面的string，蕴含了很多精妙的设计思想。

一个月以前我写了一篇讨论[字符串的驻留（string interning）][string interning]的文章，我今天将会以字符串的驻留为基础，进一步来讨论.NET中的string。string interning的基本前提是string的恒定性（immutability），即string一旦被创建将不会改变。我们就先来谈谈string的恒定性。

**一、 string是恒定的（immutable）**

和其他类型比较，string最为显著的一个特点就是它具有恒定不变性：我们一旦创建了一个string，在managed heap 上为他分配了一块连续的内存空间，我们将不能以任何方式对这个string进行修改使之变长、变短、改变格式。所有对这个string进行各项操作（比如调用ToUpper获得大写格式的string）而返回的string，实际上另一个重新创建的string，其本身并不会产生任何变化。

String的恒定性具有很多的好处，它首先保证了对于一个既定string的任意操作不会造成对其的改变，同时还意味着我们不用考虑操作string时候出现的线程同步的问题。在string恒定的这些好处之中，我觉得最大的好处是：它成就了字符串的驻留。

CLR通过一个内部的interning table保证了CLR只维护具有不同字符序列的string，任何具有相同字符序列的string所引用的均为同一个string对象，同一段为该string配分的内存快。字符串的驻留极大地较低了程序执行对内存的占用。

对于string的恒定性和字符串的驻留，还有一点需要特别指出的是：string的恒定性不单单是针对某一个单独的AppDomain，而是针对一个进程的。

**二、 String可以跨AppDomain共享的（cross-appDomain）**

我们知道，在一个托管的环境下，Appdomain是托管程序运行的一个基本单元。AppDomain为托管程序提供了良好的隔离机制，保证在同一个进程中的不同的Appdomain不可以共享相同的内存空间。在一个Appdomain创建的对象不能被另一个Appdomain直接使用，对象在AppDomain之间传递需要有一个Marshaling的过程：对象需要通过by reference或者by value的方式从一个Appdomain传递到另一个Appdomain。具体内容可以参照我的另一篇文章：[用Coding证明Appdomain的隔离性][Coding_Appdomain]。

但是这里有一个特例，那就是string。Appdomain的隔离机制是为了防止一个Application的对内存空间的操作对另一个Application 内存空间的破坏。通过前面的介绍，我们已经知道了string是恒定不变的、是只读的。所以它根本不需要Appdomain的隔离机制。所以让一个恒定的、只读的string被同处于一个进程的各个Application共享是没有任何问题的。

String的这种跨AppDomain的恒定性成就了基于进程的字符串驻留：一个进程中各个Application使用的具有相同字符序列的string都是对同一段内存的引用。我们将在下面通过一个Sample来证明这一点。

**三、 证明string垮AppDomain的恒定性**

在写这篇文章的时候，我对如何证明string跨AppDomain的interning，想了好几天，直到我偶然地想到了为实现线程同步的lock机制。

我们知道在一个多线程的环境下，为了避免并发操作导致的数据的不一致性，我们需要对一个对象加锁来阻止该对象被另一个线程 操作。相反地，为了证明两个对象是否引用的同一个对象，我们只需要在两个线程中分别对他们加锁，如果程序执行的效果和对同一个对象加锁的情况完全一样的话，那么就可以证明这两个被加锁的对象是同一个对象。基于这样的原理我们来看看我们的Sample：

![None.gif][] using  System;  
![None.gif][] using  System.Collections.Generic;  
![None.gif][] using  System.Text;  
![None.gif][] using  System.Threading;  
![None.gif][]  
![None.gif][] namespace  Artech.ImmutableString  
![ExpandedBlockStart.gif][] \{  
![InBlock.gif][]class Program  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][]staticvoid Main(string\[\] args)  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][] AppDomain appDomain1 = AppDomain.CreateDomain("Artech.AppDomain1");  
![InBlock.gif][] AppDomain appDomain2 = AppDomain.CreateDomain("Artech.AppDomain2");  
![InBlock.gif][]  
![InBlock.gif][] MarshalByRefType marshalByRefObj1 = appDomain1.CreateInstanceAndUnwrap("Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;  
![InBlock.gif][] MarshalByRefType marshalByRefObj2 = appDomain2.CreateInstanceAndUnwrap("Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;  
![InBlock.gif][]  
![InBlock.gif][] marshalByRefObj1.StringLockHelper ="Hello World";  
![InBlock.gif][] marshalByRefObj2.StringLockHelper ="Hello World";  
![InBlock.gif][]  
![InBlock.gif][] Thread thread1 =new Thread(new ParameterizedThreadStart(Execute));  
![InBlock.gif][] Thread thread2 =new Thread(new ParameterizedThreadStart(Execute));  
![InBlock.gif][]  
![InBlock.gif][] thread1.Start(marshalByRefObj1);  
![InBlock.gif][] thread2.Start(marshalByRefObj2);  
![InBlock.gif][]  
![InBlock.gif][] Console.Read();  
![ExpandedSubBlockEnd.gif][] \}  
![InBlock.gif][]  
![InBlock.gif][]staticvoid Execute(object obj)  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][] MarshalByRefType marshalByRefObj = obj as MarshalByRefType;  
![InBlock.gif][] marshalByRefObj.ExecuteWithStringLocked();  
![ExpandedSubBlockEnd.gif][] \}  
![ExpandedSubBlockEnd.gif][] \}  
![InBlock.gif][]  
![InBlock.gif][]class MarshalByRefType : MarshalByRefObject  
![ExpandedSubBlockStart.gif][]\{  
![ExpandedSubBlockStart.gif][]\#region Private Fields  
![InBlock.gif][]privatestring \_stringLockHelper;  
![InBlock.gif][]privateobject \_objectLockHelper;  
![ExpandedSubBlockEnd.gif][]\#endregion  
![InBlock.gif][]  
![ExpandedSubBlockStart.gif][]\#region Public Properties  
![InBlock.gif][]publicstring StringLockHelper  
![ExpandedSubBlockStart.gif][]\{  
![ExpandedSubBlockStart.gif][]get\{ return \_stringLockHelper; \}  
![ExpandedSubBlockStart.gif][]set\{ \_stringLockHelper = value; \}  
![ExpandedSubBlockEnd.gif][] \}  
![InBlock.gif][]  
![InBlock.gif][]publicobject ObjectLockHelper  
![ExpandedSubBlockStart.gif][]\{  
![ExpandedSubBlockStart.gif][]get\{ return \_objectLockHelper; \}  
![ExpandedSubBlockStart.gif][]set\{ \_objectLockHelper = value; \}  
![ExpandedSubBlockEnd.gif][] \}  
![ExpandedSubBlockEnd.gif][]\#endregion  
![InBlock.gif][]  
![ExpandedSubBlockStart.gif][]\#region Public Methods  
![InBlock.gif][]publicvoid ExecuteWithStringLocked()  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][]lock (this.\_stringLockHelper)  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][] Console.WriteLine("The operation with a string locked is executed\\n\\tAppDomain:\\t\{0\}\\n\\tTime:\\t\\t\{1\}",  
![InBlock.gif][] AppDomain.CurrentDomain.FriendlyName, DateTime.Now);  
![InBlock.gif][] Thread.Sleep(10000);  
![ExpandedSubBlockEnd.gif][] \}  
![ExpandedSubBlockEnd.gif][] \}  
![InBlock.gif][]  
![InBlock.gif][]publicvoid ExecuteWithObjectLocked()  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][]lock (this.\_objectLockHelper)  
![ExpandedSubBlockStart.gif][]\{  
![InBlock.gif][] Console.WriteLine("The operation with a object locked is executed\\n\\tAppDomain:\\t\{0\}\\n\\tTime:\\t\\t\{1\}",  
![InBlock.gif][] AppDomain.CurrentDomain.FriendlyName, DateTime.Now);  
![InBlock.gif][] Thread.Sleep(10000);  
![ExpandedSubBlockEnd.gif][] \}  
![ExpandedSubBlockEnd.gif][] \}  
![ExpandedSubBlockEnd.gif][]\#endregion  
![ExpandedSubBlockEnd.gif][] \}  
![ExpandedBlockEnd.gif][]\}

我们来简单地分析一下上面的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方法。我们来看看运行后的输出结果：

![performance_02_01.jpg][]

从上面的输出结果中可以看出，两个分别在不同线程中执行操作对应的AppDomain的name分别为Artech.AppDomain1和Artech.AppDomain2。执行的时间（确切地说是操作成功地对MarshalByRefType对象的\_stringLockHelper字段进行加锁的时间）相隔10s，也就是我们在程序中定义的时间延迟。

为什么会出现这样的结果呢？我们只是对两个处于不同AppDomain的不同的MarshalByRefType对象的stringLockHelper字段进行加锁。由于我们是同时开始他们对应的线程，照理说它们之间不会有什么关联，显示出来的时间应该是相同的。唯一的解释就是：虽然这两个在不同的AppDomain中创建的对象是两个完全不同的对象，由于他们的stringLockHelper字段具有相同的字符序列，它们引用的是同一个string。这就证明了我们提出的跨AppDomain进行string interning的结论。

为了进一步印证我们的结论，我们是使两个MarshalByRefObject对象的stringLockHelper字段具有不同的值，看看结果又如何。于是我们把其中一个对象的stringLockHelper字段改为”Hello World!”(多加了一个！) 。

![None.gif][] marshalByRefObj1.StringLockHelper  =  " Hello World " ;  
![None.gif][]marshalByRefObj2.StringLockHelper  =  " Hello World! " ;  
![None.gif][]

看看现在的输出结果，现在的时间是一样了。

![performance_02_02.jpg][]  
上面我们做的是对string类型字段加锁的试验。那么我们对其他类型的对象进行加锁，又会出现怎么的情况呢？我们现在就来做这样试验：在各自的线程中调用两个对象的ExecuteWithObjectLocked方法。我们修改Execute方法和Main（）。

![None.gif][] static  void  Execute( object  obj)  
![ExpandedBlockStart.gif][] \{  
![InBlock.gif][] MarshalByRefType marshalByRefObj = obj as MarshalByRefType;  
![InBlock.gif][] marshalByRefObj. ExecuteWithObjectLocked ();  
![ExpandedBlockEnd.gif][]\}

![None.gif][] static  void  Main( string \[\] args)  
![ExpandedBlockStart.gif][] \{  
![InBlock.gif][] AppDomain appDomain1 = AppDomain.CreateDomain("Artech.AppDomain1");  
![InBlock.gif][] AppDomain appDomain2 = AppDomain.CreateDomain("Artech.AppDomain2");  
![InBlock.gif][]  
![InBlock.gif][] MarshalByRefType marshalByRefObj1 = appDomain1.CreateInstanceAndUnwrap("Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;  
![InBlock.gif][] MarshalByRefType marshalByRefObj2 = appDomain2.CreateInstanceAndUnwrap("Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;  
![InBlock.gif][]  
![InBlock.gif][]object obj =newobject();  
![InBlock.gif][] marshalByRefObj1.ObjectLockHelper = obj;  
![InBlock.gif][] marshalByRefObj2.ObjectLockHelper = obj;  
![InBlock.gif][]  
![InBlock.gif][] Thread thread1 =new Thread(new ParameterizedThreadStart(Execute));  
![InBlock.gif][] Thread thread2 =new Thread(new ParameterizedThreadStart(Execute));  
![InBlock.gif][]  
![InBlock.gif][] thread1.Start(marshalByRefObj1);  
![InBlock.gif][] thread2.Start(marshalByRefObj2);  
![InBlock.gif][]  
![InBlock.gif][] Console.Read();  
![ExpandedBlockEnd.gif][] \}   
![None.gif][]

我们先来看看运行后的输出结果：

![performance_02_03.jpg][]  
我们发现两个时间是一样的，那么就是说两个对象的ObjectLockHelper引用的不是同一个对象。虽然上面的程序很简单，我觉得里面涉及的规程却很值得一说。我们来分析下面3段代码。

![None.gif][] object  obj  =  new  object ();  
![None.gif][]marshalByRefObj1.ObjectLockHelper  =  obj;  
![None.gif][]marshalByRefObj2.ObjectLockHelper  =  obj;  
![None.gif][]

简单看起来，两个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操作指令进行操作和利用字符串驻留。**

比如：

![None.gif][] string  s  =  " abc "  \+  " def " ;

优于

![None.gif][] string  s  =  " abc " ;  
![None.gif][]s  =  s  \+  " def " ;  
![None.gif][]

**2. 在需要的时候使用StringBuilder对string作频繁的操作：**

由于string的恒定性，在我们对一个string进行某些操作的时候，比如调用ToUpper（）或者ToLower（）把某个string每个字符转化成大写或者小写；调用SubString（）取子串；会创建一个新的string，有时候会创建一些新的临时string。这样的操作会增加内存的压力。所有在对string作频繁操作的情况下，我们会考虑使用StringBuilder来高效地操作string。StringBuilder之所以能对string操作带来更好的performance，是因为在它的内部维护一个字符数组，而不是一个string来避免string操作带来的新的string的创建。

StringBuilder是一个很好的字符累加器，我们应该充分地利用这一个功能：

![None.gif][] StringBuilder sb  =  new  StringBuilder();  
![None.gif][]sb.Append(str1  \+  str2);  
![None.gif][]

最好写成

![None.gif][] StringBuilder sb  =  new  StringBuilder();  
![None.gif][]sb.Append(str1);  
![None.gif][]sb.Append(str2);  
![None.gif][]

避免创建一个新的临时string来保存str1 + str2。

再比如下面的Code

![None.gif][] StringBuilder sb  =  new  StringBuilder();  
![None.gif][]sb.Append（WorkOnString1（））;  
![None.gif][]sb.Append（WorkOnString2（））;  
![None.gif][]sb.Append（WorkOnString3（））;  
![None.gif][]

最好写好吧WorkOnString1，WorkOnString2，WorkOnString3定义成：

![None.gif][] WorkOnString1（StringBuilder sb）  
![None.gif][]WorkOnString2（StringBuilder sb）  
![None.gif][]WorkOnString3（StringBuilder sb）  
![None.gif][]

**3. 高效地进行string的比较操作**

我们知道，对象之间的比较有比较Value和比较Reference之说。一般地对Reference进行比较的速度最快。对于string，在字符串驻留的前提下，我们可以把对Value的比较用Reference的比较来代替从而会的Performance的提升。

此外，对于忽略大小写的比较，我们最好使用string的static方法Compare(string strA, string strB, bool ignoreCase)。也就是说：

![None.gif][] if （str1.ToLower() == str2.ToLower()）

最好写成

![None.gif][] If（ string . Compare(str1,str2, true )）

用 str1==str2  
来比较,具体发生了什么?

1. public static bool operator ==(string a, string b)
    {
    return Equals(a, b);
    }
    
    2. public static bool Equals(string a, string b)
    {
    if (a == b)
    {
    return true;
    }
    if ((a != null) && (b != null))
    {
    return EqualsHelper(a, b);
    }
    return false;
    }
    
    3. [ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
    private static unsafe bool EqualsHelper(string strA, string strB)
    {
    int length = strA.Length;
    if (length != strB.Length)
    {
    return false;
    }
    fixed (char* text = ((char*) strA))
    {
    char* chPtr = text;
    fixed (char* text2 = ((char*) strB))
    {
    char* chPtr2 = text2;
    char* chPtr3 = chPtr;
    char* chPtr4 = chPtr2;
    while (length >= 10)
    {
    if ((((*(((int*) chPtr3)) != *(((int*) chPtr4))) || (*(((int*) (chPtr3 + 2))) != *(((int*) (chPtr4 + 2))))) || ((*(((int*) (chPtr3 + 4))) != *(((int*) (chPtr4 + 4)))) || (*(((int*) (chPtr3 + 6))) != *(((int*) (chPtr4 + 6)))))) || (*(((int*) (chPtr3 + 8))) != *(((int*) (chPtr4 + 8)))))
    {
    break;
    }
    chPtr3 += 10;
    chPtr4 += 10;
    length -= 10;
    }
    while (length > 0)
    {
    if (*(((int*) chPtr3)) != *(((int*) chPtr4)))
    {
    break;
    }
    chPtr3 += 2;
    chPtr4 += 2;
    length -= 2;
    }
    return (length <= 0);
    }
    }
    }

[String Interning]: http://www.cnblogs.com/artech/archive/2007/03/04/663728.html
[None.gif]: /images/20220327/bc4dde1e93d04c40a18794f651b5c857.png
[ExpandedBlockStart.gif]: /images/20220327/da2e598f6bce4f8f9a94e143710c66a1.png
[InBlock.gif]: /images/20220327/1279f2fc81f04595ac24bbe38aafcbce.png
[ExpandedBlockEnd.gif]: /images/20220327/d91f8174aebe47d4872c3679bf08fe46.png
[string_interning_01.jpg]: /images/20220327/2ec3fd54bb754b22bc0d1de83c4c1820.png
[Managed Code_Performance_Scalability_string_string]: http://www.cnblogs.com/artech/archive/2007/05/06/737130.html
[Artech]: http://artech.cnblogs.com/
[string interning]: http://www.cnblogs.com/artech/archive/2007/03/04/663728.aspx
[Coding_Appdomain]: http://www.cnblogs.com/artech/archive/2007/03/05/664825.aspx
[ExpandedSubBlockStart.gif]: /images/20220327/725e6899073b45aeb08cb70b68c43143.png
[ExpandedSubBlockEnd.gif]: /images/20220327/cb2a8e651d954d7ea7d501e70bcd973b.png
[performance_02_01.jpg]: /images/20220327/4af03f9874754dea844399264ee304a3.png
[performance_02_02.jpg]: /images/20220327/c792aa90db8841bd990ce5035c3ff07f.png
[performance_02_03.jpg]: /images/20220327/9e398f264e9745c08ce65f20deaf620a.png