一起谈.NET技术,深入理解string和如何高效地使用string

  一个月以前我写了一篇讨论字符串的驻留(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的隔离性

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

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

  三、证明string垮AppDomain的恒定性

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

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

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace Artech.ImmutableString
{
    class Program
    {
        static void Main(string[] args)
        {
            AppDomain appDomain1 = AppDomain.CreateDomain("Artech.AppDomain1");
            AppDomain appDomain2 = AppDomain.CreateDomain("Artech.AppDomain2");

            MarshalByRefType marshalByRefObj1 = appDomain1.CreateInstanceAndUnwrap(
"Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;
            MarshalByRefType marshalByRefObj2 = appDomain2.CreateInstanceAndUnwrap(
"Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;

            marshalByRefObj1.StringLockHelper = "Hello World";
            marshalByRefObj2.StringLockHelper = "Hello World";

            Thread thread1 = new Thread(new ParameterizedThreadStart(Execute));
            Thread thread2 = new Thread(new ParameterizedThreadStart(Execute));

            thread1.Start(marshalByRefObj1);
            thread2.Start(marshalByRefObj2);

            Console.Read();            
        }

        static void Execute(object obj)
        
            MarshalByRefType marshalByRefObj = obj as MarshalByRefType;
            marshalByRefObj.ExecuteWithStringLocked();
        }
    }

    class MarshalByRefType : MarshalByRefObject
    {
        Private Fields#region Private Fields
        private string _stringLockHelper;
        private object _objectLockHelper;
        #endregion

        Public Properties#region Public Properties
        public string StringLockHelper
        {
            get { return _stringLockHelper; }
            set { _stringLockHelper = value; }
        }

        public object ObjectLockHelper
        {
            get { return _objectLockHelper; }
            set { _objectLockHelper = value; }
        }
        #endregion

        Public Methods#region Public Methods
        public void ExecuteWithStringLocked()
        {
            lock (this._stringLockHelper)
            {
                Console.WriteLine("The operation with a string locked is executed\n\tAppDomain:\t{0}\n\tTime:\t\t{1}",
                   AppDomain.CurrentDomain.FriendlyName, DateTime.Now);
                Thread.Sleep(10000);
            }
        }

        public void ExecuteWithObjectLocked()
        {
            lock (this._objectLockHelper)
            {
                Console.WriteLine("The operation with a object locked is executed\n\tAppDomain:\t{0}\n\tTime:\t\t{1}",
                   AppDomain.CurrentDomain.FriendlyName, DateTime.Now);
                Thread.Sleep(10000);
            }
        }
        #endregion
    }
}

  我们来简单地分析一下上面的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!”(多加了一个!) 。

marshalByRefObj1.StringLockHelper = "Hello World";
marshalByRefObj2.StringLockHelper = "Hello World!";

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

  上面我们做的是对string类型字段加锁的试验。那么我们对其他类型的对象进行加锁,又会出现怎么的情况呢?我们现在就来做这样试验:在各自的线程中调用两个对象的ExecuteWithObjectLocked方法。我们修改Execute方法和Main()。

static void Execute(object obj)
        
            MarshalByRefType marshalByRefObj = obj as MarshalByRefType;
            marshalByRefObj. ExecuteWithObjectLocked ();
}

static void Main(string[] args)
        {
            AppDomain appDomain1 = AppDomain.CreateDomain("Artech.AppDomain1");
            AppDomain appDomain2 = AppDomain.CreateDomain("Artech.AppDomain2");

            MarshalByRefType marshalByRefObj1 = appDomain1.CreateInstanceAndUnwrap(
"Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;
            MarshalByRefType marshalByRefObj2 = appDomain2.CreateInstanceAndUnwrap(
"Artech.ImmutableString", "Artech.ImmutableString.MarshalByRefType") as MarshalByRefType;

            object obj = new object();
            marshalByRefObj1.ObjectLockHelper = obj;
            marshalByRefObj2.ObjectLockHelper = obj;

            Thread thread1 = new Thread(new ParameterizedThreadStart(Execute));
            Thread thread2 = new Thread(new ParameterizedThreadStart(Execute));

            thread1.Start(marshalByRefObj1);
            thread2.Start(marshalByRefObj2);

            Console.Read();            
        }

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

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

object obj = new object();
marshalByRefObj1.ObjectLockHelper = obj;
marshalByRefObj2.ObjectLockHelper = obj;

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

  比如:

string s = "abc" + "def";

  优于:

string s = "abc";
s = s + "def";

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

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

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

StringBuilder sb = new StringBuilder();
sb.Append(str1 + str2);

  最好写成:

StringBuilder sb = new StringBuilder();
sb.Append(str1);
sb.Append(str2);

  避免创建一个新的临时string来保存str1 + str2。再比如下面的Code:

StringBuilder sb = new StringBuilder();
sb.Append(WorkOnString1());
sb.Append(WorkOnString2());
sb.Append(WorkOnString3());

  最好写好吧WorkOnString1,WorkOnString2,WorkOnString3定义成:

WorkOnString1(StringBuilder sb)
WorkOnString2(StringBuilder sb)
WorkOnString3(StringBuilder sb)

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

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

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

if(str1.ToLower()==str2.ToLower())

  最好写成:

If(string. Compare(str1,str2,true))

时间: 2024-10-24 13:39:16

一起谈.NET技术,深入理解string和如何高效地使用string的相关文章

深入理解string和如何高效地使用string

无论你所使用的是哪种编程语言,我们都不得不承认这样一个共识:string是我们使用最为频繁的一种对象.但是string的常用性并不意味着它的简单性,而且我认为,正是由于string的频繁使用才会促使其设计人员在string的设计上花大量的功夫.所以正是这种你天天见面的string,蕴含了很多精妙的设计思想. 一个月以前我写了一篇讨论字符串的驻留(string interning)的文章,我今天将会以字符串的驻留为基础,进一步来讨论.NET中的string.string interning的基本前

一起谈.NET技术,理解POCO

理解POCO先要理解POJO 1.什么是POJO POJO的名称有多种,pure old java object .plain ordinary java object 等. 按照Martin Fowler的解释是"Plain Old Java Object",从字面上翻译为"纯洁老式的java对象",但大家都使用"简单java对象"来称呼它. POJO的内在含义是指那些没有从任何类继承.也没有实现任何接口,更没有被其它框架侵入的java对象.

一起谈.NET技术,理解.NET程序集的执行过程

对于一个已编译好的.NET程序集,Windows操作系统是如何启动执行的呢?日常使用中我们发现对于托管的和非托管的程序集编译器都会吧程序集编译成以.exe或.dll等为扩展名的文件,可见Windows加载器并没有区分是托管还是非托管的程序集,而且我们也知道对非托管的程序集是在编译器直接编译成了机器码,自然可以由CPU直接执行,而托管的.NET 程序集是包含复杂结构的MSIL代码,执行时会使用JIT即时编译器将IL代码编译成机器码,再由CPU执行,当然这期间还需要执行其它许多的工作,如加载CLR.

一起谈.NET技术,WPF Multi-Touch 开发:高效开发模式

在前几篇文章中已经介绍了触屏操作的多种模式,并对其开发方式也有了进一步了解.细心的朋友应该会发现在上一篇文章中,如果拖动图片过快它会因惯性效果飞出程序窗口外,也就是说还需要对其进行边界限制等相关开发.而且无论是哪种触屏操作都需要开发者逐行逐句的编写代码,本篇将为大家介绍一种高效的多点触屏开发模式. 其实我们只需利用CodePlex 中的Multi-Touch Manipulation 项目即可,该程序不仅支持WPF,还可以进行Silverlight 和Windows Phone 7 的项目开发.

一起谈.NET技术,WPF 基础到企业应用系列3——WPF开发漫谈

1.开篇前言      首先很高兴这个系列能得到大家的关注和支持,基于对大家负责和对自己负责的态度,我会不断努力写好这个系列,分享自己的微薄技术和经验,希望在帮助别人的同时也不断提升自己.由于这篇文章稍多,所以读者花的时间长了一些,也希望大家能够见谅,这个系列以后会每周发三到四篇左右(主要是写一篇差不多要花几晚上,感觉思维比较发散),除了讲WPF技术本身之外,也会讲一些项目具体开发,所以敬请关注.在前两次的文章中我们对WPF有了一个比较全面的认识,那么在本篇文章当中,除了讲一些理论知识外,我们会

一起谈.NET技术,Silverlight 2.5D RPG游戏技巧与特效处理:(二)纸娃娃系统

纸娃娃系统,或许大家听起来并不陌生.早在十几年前,当时不论是文字游戏"泥巴(Mud)"或是交友.社交网站,我们只能通过屏幕上的文字来传达与交互信息:随着技术不断进步,2D/3D图形技术高速崛起,通过在基础模型上由客户随意挑选.任意更换各种造型(素材),即可打造出真正属于"自我"独特风格的网络虚拟形象,QQ秀便是我们耳熟能详的代表,更贴近真实的如(RPG)游戏及虚拟现实中的换装/换肤系统同样亦得益于纸娃娃机制. 本节,我将向大家讲解如何最好的实现Silverlight

一起谈.NET技术,由扩展方法引申出的编程思维

1. Helper大爆炸 .NET Framework为我们提供了丰富的类库,但是这并不是万能地,在大部分的时间,我们都需要为我们的项目特殊定制我们的通用类库. 常常,我们都可以构造一个类,类里封装一些方法.但是对于很多时候,我们并没有办法提取出这样一个类,举一个小例子,我们在很多时候,需要把url给保存到数据库里,作为一个唯一标识,但是我们知道url所占空间很大,如果用url来建立索引的话是非常耗费空间,而且影响效率的,那么我们最常用的办法就是把url做一个Hash来作为索引的替代品. 这个时

一起谈.NET技术,2010 .NET面试题整理之基础篇

开篇语:对于已有工作经验的朋友,也许面试题已显得不怎么重要,但是如果你应聘的还仅仅是个普通的程序员,相信在很多的公司都还是会先拿出一套面试题,可能对整个面试影响不大,但做好面试题无疑会赢得第一个好的印象,特别对于那些缺少项目经验的应届毕业生.很多时候,在看这些面试题的时候,是否有感过曾经那些一个个不起眼的小程序题所针对的问题正是自己在项目中所犯的错误?是否会发现,原来还有这么多东西自己都还从未去想过?趁自己这次重新找工作之际,对常见面试题进行进行一次重新整理,与大家共同学习!本贴将会进行不断完善

【区块链之技术进阶】从技术现实理解区块链:基于SQL模型创建BQL

在前面的两篇文章里,咱们看到了知乎上的两位妹纸关于区块链的理解,一位从金融角度切入同时兼顾了技术概况,另一位呢则偏重于技术层面(一言不合就放代码).通过两位妹子(萌萌哒)的叙述,想必大家对于区块链有了更深的理解,并且巧合的是两位妹子都不约而同提到了创世区块链,这在咱们之前的文章中很少提到的.(是不是妹纸写文章更细心,这我就不知道了...)读完上一篇文章中的妹子画的图大家是不是对于"区块分叉"还有"共识攻击"的技术原理更加理解了呢?毕竟图中有妹子的自拍... 本文是[