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

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

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

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

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Press any key to begin building string...");
        Console.ReadLine();
        BuildString();
        Console.WriteLine("Press any key to exit...");
        Console.ReadLine();
    }

    static void BuildString()
    {
        var str1 = "ABCDEFG";
        var str2 = "ABCDEFG";
        var str3 = "1234678";
        var str4 = "1234678";
    }
}

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

图1

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

图2

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

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

static void BuildString()
{
    var str1 = "ABCDEFG";
    var str2 = "ABCD" +"EFG";
    var str3 = "1234678";
    var str4 = "1234"+"678";
}

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

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

static void BuildString()
{
    var str1 = "ABCDEFG";
    var str2 = "1234678";
    var str3 = "ABCDEFG" + str2;
    var str4 = str1 + "1234678";
    var str5 = str1 + str2;
}

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

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

static void BuildString()
{
    var str1 = "ABCDEFG";
    var str2 = "1234678";
    var str3 = string.Intern("ABCDEFG" + str2);
}

通过采用上面的Profiling流程,在新创建对象(New Object)String实例列表中,多出了一个“ABCDEFG1234678”。

图3

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

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

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Press any key to begin building string...");
        Console.ReadLine();
        BuildString();
        GC.Collect();
        Console.WriteLine("Press any key to exit...");
        Console.ReadLine();
    }

    static void BuildString()
    {
        var str1 = "ABCDEFG";
        var str2 = "ABCDEFG";
        var str3 = "1234678";
        var str4 = "1234678";
    }
}

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

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

public class AppDomainContext
{
    public AppDomain AppDomain { get; private set; }
    private AppDomainContext(string friendlyName)
    {
        this.AppDomain = AppDomain.CreateDomain(friendlyName);
    }
    public static AppDomainContext CreateDomainContext(string friendlyName)
    {
        return new AppDomainContext(friendlyName);
    }
    public void Invoke<T>(Action<T> action)
    {
        T instance = (T)this.AppDomain.CreateInstanceAndUnwrap(typeof(T).Assembly.FullName, typeof(T).FullName);
        action(instance);
    }
}

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

public class Foo : MarshalByRefObject
{
    public void BuildString()
    {
        var str1 = "ABCDEFG";
        var str2 = "ABCDEFG";
        var str3 = "1234678";
        var str4 = "1234678";
    }
}

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

static void Main(string[] args)
{
    Console.WriteLine("Press any key to begin building string...");
    Console.ReadLine();
    AppDomainContext.CreateDomainContext("Domain A").Invoke<Foo>(foo => foo.BuildString());
    AppDomainContext.CreateDomainContext("Domain B").Invoke<Foo>(foo => foo.BuildString());
    AppDomainContext.CreateDomainContext("Domain C").Invoke<Foo>(foo => foo.BuildString());
    GC.Collect();
    Console.WriteLine("Press any key to exit...");
    Console.ReadLine();
}

到此这篇关于C#字符串内存驻留机制分析的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • C#字符串内存分配与驻留池学习分享

    刚开始学习C#的时候,就听说CLR对于String类有一种特别的内存管理机制:有时候,明明声明了两个String类的对象,但是他们偏偏却指向同一个实例.如下: 复制代码 代码如下: String s1 ="Hello";String s2 ="Hello";                       //s2和s1的实际值都是Hellobool same = (object) s1 == (object) s2;//这里比较s1.s2是否引用了同一个对象实例//所

  • C# 字符串string和内存流MemoryStream及比特数组byte[]之间相互转换

    定义string变量为str,内存流变量为ms,比特数组为bt 1.字符串转比特数组 复制代码 代码如下: (1)byte[] bt=System.Text.Encoding.Default.GetBytes("字符串"); (2)byte[] bt=Convert.FromBase64String("字符串"); 2.字符串转流 复制代码 代码如下: (1)MemoryStream ms=new MemoryStream(System.Text.Encoding.

  • C#之CLR内存字符串常量池(string)

    C#中的string是比特殊的类,说引用类型,但不存在堆里面,而且String str=new String("HelloWorld")这样的重装也说没有的. 我们先来看一个方法: class Program { static void Main(string[] args) { String s = "HelloWorld"; Console.WriteLine(s); } } 然后我们用ildasm.exe工具把它生成IL语言来看一看它里面是怎么玩的: .met

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

    在这之前我写过一些文章来介绍关于字符串内存分配和驻留的文章,涉及到的观点主要有:字符串的驻留机制避免了对具有相同字符序列的字符串对象的重复创建:被驻留的字符串是不受GC管辖的,即被驻留的字符串对象不能被GC回收:被驻留的字符串是被同一进程中所有应用程序域共享的.至于具体的原因,相信在<关于CLR内存管理一些深层次的讨论>中,你可以找到答案.由于这些天来在做一些关于内存泄露审查的工作,所以想通过具体的Memory Profiling工具来为你证实上面的结论.我采用的Memory Profilin

  • 字符串内存驻留机制详解示例

    复制代码 代码如下: //字符串的内存驻留机制        public static void Test()        {            //当有多个字符串变量包含了同样的字符串实际值时,            //CLR可能不会为它们重复地分配内存,而是让它们统统指向同一个字符串对象实例. String s1 = "Hello";            String s2 = "Hello";            bool same = (obj

  • python 字符串的驻留机制及优缺点

    说明 字符串驻留是一种仅保存一份相同且不可变字符串的方法.不同的值被存放在字符串驻留池中,发生驻留之后, 许多变量可能指向内存中的相同字符串对象, 从而节省内存. 原理 系统维护interned字典,记录已被驻留的字符串对象 当字符串对象a需要驻留时,先在interned检测是否存在,若存在则指向存在的字符串对象,a的引用计数减1 若不存在,则记录a到interned中 驻留时机 所有长度为 0 和长度为 1 的字符串都被驻留 字符串只在编译时进行驻留,而非运行时 a = 'hi' # a变量被

  • java 字符串内存分配的分析与总结(推荐)

    经常在网上各大版块都能看到对于java字符串运行时内存分配的探讨,形如:String a = "123",String b = new String("123"),这两种形式的字符串是存放在什么地方的呢,其实这两种形式的字符串字面值"123"本身在运行时既不是存放在栈上,也不是存放在堆上,他们是存放在方法区中的某个常量区,并且对于相同的字符串字面值在内存中只保留一份.下面我们将以实例来分析. 1.==运算符作用在两个字符串引用比较的两个案例: p

  • Python中的 is 和 == 以及字符串驻留机制详解

    is 和 == 先了解下官方文档中关于 is 和 == 的概念.is 表示的是对象标示符(object identity),而 == 表示的是相等(equality):is 的作用是用来检查对象的标示符是否一致,也就是比较两个对象在内存中的地址是否一样(相当于检查 id(a) == id(b)),而 == 是用来检查两个对象引用的值是否相等(相当于检查 a.eq(b)):这点和Java有点类似,只不过Java中是用 == 来比较两个对象在内存中的地址,用 equals() 来检查两者之间的值是否

  • Python 内存管理机制全面分析

    内存管理: 概述 在Python中,内存管理涉及到一个包含所有Python对象和数据结构的私有堆(heap). 这个私有堆的管理由内部的Python内存管理器保证.Python内存管理器有不同的组件来处理各种动态存储管理方面的问题,如共享,分割,预分配或缓存. 在最底层,一个原始内存分配器通过与操作系统的内存管理器交互,确保私有堆有足够的空间来存储所有与Python相关的数据.在原始内存分配器的基础上,几个对象特定的分配器在同一个堆上运行,并根据每种对象类型的特点实现不同的内存管理策略.例如,整

  • Python字符串的创建和驻留机制详解

    目录 字符串 字符串驻留机制 字符串驻留机制优缺点 字符串 字符串在Python中是基本数据类型,是一个不可变的字符序列. 字符串驻留机制 仅保存一份相同且不可变字符串的方法,不同的值被存放在字符串的驻留池中,Python的驻留机制对相同的字符串只保留一份拷贝,后续创建相同字符串时,不会开辟新空间,而是把该字符串的地址赋给新创建的变量. 驻留机制的几种情况(交互模式windows+r,cmd) 1.字符串的长度为0或1时 2.符合标识符的字符串 3.字符串只在编译时进行驻留,而非运行时 b在运行

  • 详解Python中神奇的字符串驻留机制

    目录 1 什么是字符串驻留机制 2 如何使用字符串驻留机制 3 简单拼接驻留, 运行时不驻留 4 总结 5 全部代码 今天有一个初学者在学习Python的时候又整不会了. 原因是以下代码: a = [1, 2, 3] b = [1, 2, 3] if a is b: print("a and b point to the same object") else: print("a and b point to different objects") 运行结果是a an

  • python字符串驻留机制的使用范围知识点详解

    1.字符串的长度为0和1时. 2.符合标识符的字符串. 3.字符串只在编译时进行驻留,而非运行时. 4.[-5,256]之间的整数数字. 实例 >>> str1='jiumo' >>> str2='jiumo' >>> str1 is str2 True >>> id(str1) 1979078421896 >>> id(str2) 1979078421896 知识点扩充: 驻留时机 所有长度为 0 和长度为 1 的

随机推荐