C#字符串内存驻留机制分析

第C#字符串内存驻留机制分析在这之前我写过一些文章来介绍关于字符串内存分配和驻留的文章，涉及到的观点主要有：字符串的驻留机制避免了对具有相同字符序列的字符串对象的重复创建；被驻留的字符串是不受GC管辖的，即被驻留的字符串对象不能被GC回收；被驻留的字符串是被同一进程中所有应用程序域共享的。至于具体的原因，相信在《关于CLR内存管理一些深层次的讨论》中，你可以找到答案。由于这些天来在做一些关于内存泄露审查的工作，所以想通过具体的MemoryProfiling工具来为你证实上面的结论。我采用的MemoryProfiling工具是RedGate的ANTSMemoryProfiler，陷于篇幅问题我不对该工具进行详细的介绍，有兴趣的朋友可以登录它的官网。

一、具有相同字符序列的String对象不会重复创建

首先来证明第一个结论：具有相同字符序列的String对象不会重复创建。我先创建了一个简单的Console应用，编写了如下的程序：在静态方法BuildString中进行了四次String对象的创建，str1和str2，str3和str4具有相同的值。该方法在Main方法中被执行，在执行前后通过调用Console.ReadLine方法让程序Block住。

classProgram

staticvoidMain(string[]args)

Console.WriteLine("Pressanykeytobeginbuildingstring...");

Console.ReadLine();

BuildString();

Console.WriteLine("Pressanykeytoexit...");

Console.ReadLine();

staticvoidBuildString()

varstr1="ABCDEFG";

varstr2="ABCDEFG";

varstr3="1234678";

varstr4="1234678";

}

现在我们通过ANTSMemoryProfiler启动代码这个Console程序的exe文件，在静态方法前后（也就是相应的文字被输出到控制台的时候）拍摄两个内存快照。通过比较这两个快照下对象的变化，我们发现多了3个String类型的实例。

图1

我们进一步追踪着多出的3个字符串的值到底是多少，于是我们查看实例列表。从下面的截图中我们可以清晰地看到：除了一个值为byteIndex的字符串之外，另两个的值分别为ABCDEFG和12345678，它们就是我们在静态方法BuildString创建的。在BuildString方法中，我们创建了4个String对象，而在这里我们我们只看到了两个。这无疑证实了字符串驻留机制的存在。

图2

二、字符串驻留机制同样于stringliteral+stringliteral的运算

+是我们最为常见的字符串操作符，当我们通过该操作符对两个字符串进行连接操作的时候，字符串的驻留机制依然有效。为此，我将BuildString方式定义成如下的方式，采用相同的Profiling流程，你依然可以看到与图2完全一样的结果。

staticvoidBuildString()

varstr1="ABCDEFG";

varstr2="ABCD"+"EFG";

varstr3="1234678";

varstr4="1234"+"678";

}

三、字符串驻留机智不适合Variable+stringliteral形式

虽然字符串的驻留适用于两个通过引号括起来的字符串值直接进行相加，但是如果将任何一个或者两个换成字符串变量，最终运算的结果是不能被驻留的。我们同样可以通过类似于上面的步骤来证实这一点，为此我们BuildString方法进行了如下的修改。采用上面的Profiling流程，你看到的依然是图2完全一样的结果，也就是说无论是变量和一个字符串常量相加，还是两个字符串常量相加，运算的结果ABCDEFG1234678并没有被驻留下来（实际上此时它已经是一个垃圾对象，GC可以对其进行回收）。

staticvoidBuildString()

varstr1="ABCDEFG";

varstr2="1234678";

varstr3="ABCDEFG"+str2;

varstr4=str1+"1234678";

varstr5=str1+str2;

}

四、调用string.Intern可以对运算结果进行强制驻留

虽然涉及到变量的字符串连接运算结果不会被驻留，但是我们可以通过调用string.Intern方法对其进行强制驻留，该方法会迫使传入传入参数表示的字符串被保存到驻留池中。为此，我们对BuildString方法进行如下的修改：将ABCDEFG+str2运算的结构传入string.Intern静态方法中。

staticvoidBuildString()

varstr1="ABCDEFG";

varstr2="1234678";

varstr3=string.Intern("ABCDEFG"+str2);

}

通过采用上面的Profiling流程，在新创建对象（NewObject）String实例列表中，多出了一个ABCDEFG1234678。

图3

五、驻留的字符串不能被GC回收

虽然String是一个引用类型，但是它却不受GC管辖。GC在进行回收的时候，看似垃圾对象的字符串实例依然保存在内存中。为了演示，我们将BuildString方法还原成原来的代码，并在调用该方法之后调用GC.Collect方法进行强制垃圾回收。采用上面的Profiling流程，你看到的依然是图2完全一样的结果，四个本应该是垃圾对象（str1~str4）在GC回收之后依然存在。

classProgram

staticvoidMain(string[]args)

Console.WriteLine("Pressanykeytobeginbuildingstring...");

Console.ReadLine();

BuildString();

GC.Collect();

Console.WriteLine("Pressanykeytoexit...");

Console.ReadLine();

staticvoidBuildString()

varstr1="ABCDEFG";

varstr2="ABCDEFG";

varstr3="1234678";

varstr4="1234678";

}

六、字符串驻留是基于整个进程的

现在来证明最后一个结论：驻留的字符串是基于整个进程范围的，而不是基于当前AppDomain。为了证明这个结论，我们可以要写多一点代码。我们借用《关于CLR内存管理一些深层次的讨论》中的方式，创建了如下一个AppDomainContext类，该类是对一个AppDomain对象的封装。Invoke方法实现了在一个单独的AppDomain中执行某个基于泛型类型实例的操作。

publicclassAppDomainContext

publicAppDomainAppDomain{get;privateset;}

privateAppDomainContext(stringfriendlyName)

this.AppDomain=AppDomain.CreateDomain(friendlyName);

publicstaticAppDomainContextCreateDomainContext(stringfriendlyName)

returnnewAppDomainContext(friendlyName);

publicvoidInvokeT(ActionTaction)

Tinstance=(T)this.AppDomain.CreateInstanceAndUnwrap(typeof(T).Assembly.FullName,typeof(T).FullName);

action(instance);

}

然后我们将上述的BuildString方法实现在一个继承自MarshalByRefObject的Foo类型中。

publicclassFoo:MarshalByRefObject

publicvoidBuildString()

varstr1="ABCDEFG";

varstr2="ABCDEFG";

varstr3="1234678";

varstr4="1234678";

}

然后再Main方法中，我们执行如下的程序。下面的程序模拟的是创建了3个AppDomain，并在它们内部进行BuildString方法的执行。如果字符串的驻留是基于AppDomain的话，应该有6个String实例存在。但是采用上面的Profiling流程，你看到的依然图2完全一样的结果，这就充分证明了驻留机制是基于进程而非AppDomain的结论。

staticvoidMain(string[]args)

Console.WriteLine("Pressanykeytobeginbuildingstring...");

Console.ReadLine();

AppDomainContext.CreateDomainContext("DomainA").InvokeFoo(foo=foo.BuildString());

AppDomainContext.CreateDomainContext("DomainB").InvokeFoo(foo=foo.BuildString());

AppD