重谈字符串连接性能（中）：细节实现

2009-12-03 10:10 Jeffrey Zhao 阅读(10532) 评论(40) 编辑收藏举报

根据上次的评测结果，我们了解了几种字符串拼接方式的性能高低。从中可以看出，广受追捧的StringBuilder性能似乎并不是最好的，String.Concat方法有时候有时候更适合使用。那么为什么String.Concat方法性能那么高，StringBuilder又为什么落败，而我们又有没有什么可以改进的做法呢？为此，我们不妨动用.NET Reflector这一利器，看一下两者是怎么实现的。

String.Concat为什么这么快

String.Concat方法有多个重载，其中我们关注那个接受字符串数组作为参数的重载，它是实现的核心。代码如下：

public static string Concat(params string[] values)
{
    int totalLength = 0;

    if (values == null)
    {
        throw new ArgumentNullException("values");
    }

    string[] arrayToConcate = new string[values.Length];

    // 遍历源数组，填充拼接用的数组
    for (int i = 0; i < values.Length; i++)
    {
        string str = values[i];

        // null作为空字符串对待
        arrayToConcate[i] = (str == null) ? Empty : str;

        // 累计字符串总长度
        totalLength += arrayToConcate[i].Length;

        // 如果越界了，抛异常
        if (totalLength < 0)
        {
            throw new OutOfMemoryException();
        }
    }

    // 拼接
    return ConcatArray(arrayToConcate, totalLength);
}

由于数组中的字符串都是确定的，因此Concat方法可以事先计算出结果的长度，并交由ConcatArray方法进行拼接：

[MethodImpl(MethodImplOptions.InternalCall)]
private static extern string FastAllocateString(int length);

private static string ConcatArray(string[] values, int totalLength)
{
    // 分配目标字符串所占用的空间（即创建对象）
    string dest = FastAllocateString(totalLength);

    int destPos = 0;

    for (int i = 0; i < values.Length; i++)
    {
        // 不断将源字符串的每个元素填充至目标位置
        FillStringChecked(dest, destPos, values[i]);

        // 偏移量不断更新
        destPos += values[i].Length;
    }

    return dest;
}

在ConcatArray方法中，首先使用FastAllocateString分配一个长度为length的字符串对象——这是一个外部调用，由CLR实现。CLR在堆上会生成一个字符串对象（其实就是开辟一块内存，并填好一些数据），其中包含了各个字段，也就是说“结构”已经完备，而唯一所缺的便是字符串的内容。于是遍历源字符串数组，将它们一个一个复制（或叫做“填充”）到目标字符串的某一段位置上去，它所用的FilStringChecked方法实现如下：

private static unsafe void FillStringChecked(string dest, int destPos, string src)
{
    int length = src.Length;
    if (length > (dest.Length - destPos))
    {
        throw new IndexOutOfRangeException();
    }

    fixed (char* chDest = &dest.m_firstChar)
    {
        fixed (char* chSrc = &src.m_firstChar)
        {
            wstrcpy(chDest + destPos, chSrc, length);
        }
    }
}

这里使用了非安全代码，直接调用wstrcpy复制内存上的内容，wstrcpy方法的具体实现很“单纯”，我们可以不去关心它，而这里可以关注的是作内存数据复制的“位置”是哪里。从前一篇文章中我们知道，在一个字符串结构中，从对象地址偏移12字节的地方是m_firstChar字段，这个字段——更确切地说应该是“位置”包含了字符串的首地址，而往后则便是一个一个字符了。换句话说，从m_firstChar字段的地址开始便是字符串的内容，因此FillStringChecked方法在复制的时候，都是从m_firstChar开始的：从src.m_firstChar读取数据，而从dest.m_firstChar开始偏移destPos个字符的位置写入。

这便是String.Concat(string[])方法的全部实现，非常简单，清晰，但这也正是这个方法高效的原因所在。我们知道字符串是个不可变的对象，每次新建字符串都要开辟一块新空间。而String.Concat方法便将这个开辟新空间的代价减少到最小。因为在此之前已经确定结果的大小，因此直接创建一个“容器”即可，剩下的只是填充数据而已。既然可以不浪费任何一寸空间，也没有任何多余的操作，性能又怎会不高呢？

String.Concat还有一些重载，接受少量的对象进行拼接，这些方法都是单独实现，而没有委托给接受字符串数组的重载，这也是出于性能考虑——毕竟节省了构造字符串数组的开销。String.Concat方法和编译器联系紧密，属于使用最为频繁的操作之一，因此.NET在这里会尽可能榨干任何性能上的水分。

String即Builder

这个节标题有些唬人，不过这也是我最终得到的结果。可能这和平时了解的东西不太一样，对于一些初学的朋友可能不太适合去记住这个，反而会产生混淆。这其实也是我认为不能“一切都追究到底”，而必须“在一定抽象上看待事物”的原因。不过，现在我们只是在关注一个客观事实，希望这个事实不会对您产生误导。

我们从了解.NET之处便一直被告知，String对象是不可变的，因此我们没法修改一个String对象，只能新建一个。但是，上面的代码也告诉我们，String并非不可变的，它只是不允许外界进行修改，而.NET内部爱怎么动便可以怎么动。这句话从两个角度来理解会有不同感觉：1) 这是一句废话，因为所有东西都在内存里，只要能涂改内存里的数据，又有什么不是不可修改的呢？不过，2) 其实从代码上看，String对象其实原本就打算给人（自己人）修改，String了解StringBuilder的存在，而StringBuilder也只是利用了String原有的功能而已。如一言蔽之：String有可变和不可变两个方面，从外界只能看到String不可变的一面，而可变的一面由StringBuilder暴露出来。

为什么这么说呢？我们来看StringBuilder的Append方法：

public StringBuilder Append(string value)
{
    if (value != null)
    {
        string currentValue = this.m_StringValue;

        IntPtr currentThread = Thread.InternalGetCurrentThread();

        // 如果上次修改和本次修改不是同一个线程，
        if (this.m_currentThread != currentThread)
        {
            // 则复制一份当前的字符串及“容量”，
            // 避免多个线程修改同一块内存
            currentValue = string.GetStringForStringBuilder(currentValue, currentValue.Capacity);
        }

        int length = currentValue.Length;
        // 计算目标长度
        int requiredLength = length + value.Length;

        // 如果目标长度超过当前容量
        if (this.NeedsAllocation(currentValue, requiredLength))
        {
            // 则复制一个新的字符串对象，不过拥有更大的容量
            string newString = this.GetNewString(currentValue, requiredLength);
            // 把新加的部分复制到原“字符序列”的后面
            newString.AppendInPlace(value, length);
            // 保留当前线程标识符及新的字符串对象（新容量）
            this.ReplaceString(currentThread, newString);
        }
        else // 容量足够
        {
            currentValue.AppendInPlace(value, length);
            this.ReplaceString(currentThread, currentValue);
        }
    }

    return this;
}

private bool NeedsAllocation(string currentString, int requiredLength)
{
    return (currentString.ArrayLength <= requiredLength);
}

之前我们分析了String对象的结构，发现其中有两个字段，stringLength和arrayLength，其中stringLength自然表示了字符串的长度，但字符串对象的体积确是由arrayLength决定的。换句话说，假设有一个stringLength为1，arrayLength为100的字符串对象，它的大小与stringLength为90，arrayLength为100的对象完全一样。这样看来arrayLength就好比一个“容量”，表明了这个字符串对象“可以包含”的最长字符序列。事实上从上面的代码中也可以看出，String类中的确有这么一个Capacity属性：

public class String
{
    internal int Capacity
    {
        get
        {
            return (this.m_arrayLength - 1);
        }
    }
}

可见，它的值便是arrayLength——抛开最后一位填上“\0”，也因此上次我们发现，对于最“满当”的字符串，arrayLength也比stringLength多1。当然，在平时来说，我们只能创建容量与内容相同的字符串，如果真要创建一个“空荡荡”的容器，则需要调用String类的静态方法GetStringForStringBuilder——虽然这的确没有什么用途。GetStringForStringBuilder的实现我们也可以猜出，便是让CLR分别一个一定容量的字符串对象，然后从m_firstChar的地址进行内存复制而已。

在我们不断地Append之后，最后便要调用StringBuilder的ToString方法了：

public override string ToString()
{
    string currentValue = this.m_currentValue;

    if (this.m_currentThread != Thread.InternalGetCurrentThread())
    {
        return string.InternalCopy(currentValue);
    }

    // 如果这个字符串对象“太空”的话
    if ((2 * currentValue.Length) < currentValue.ArrayLength)
    {
        // 则构造一个“满当”地对象
        return string.InternalCopy(currentValue);
    }

    // 将字符序列最后放一个\0
    currentValue.ClearPostNullChar();

    // 既然容器已经“暴露”，则设制“当前线程”的标识为Zero，
    // 这意味着下次操作会生成新字符串对象（即新的容器）
    this.m_currentThread = IntPtr.Zero;

    // 如果“还不算太空”，则返回当前对象
    return currentValue;
}

StringBuilder的ToString方法比较有意思，它会判断到底是“构造一个新对象”还是就“直接返回当前容器”给你。如果直接返回当前容器，则可能会浪费较多内存，而如果构造一个新对象，则又会损耗性能。让StringBuilder做出决定的便是容器内部的字符序列占“最大容积”的比例，如果超过一半，则表明“还不算太空”，便选择“时间”，直接返回容器；否则，StringBuilder会认为还是选择“空间”较为合算，便构造一个新对象并返回，至于当前的容器便会和StringBuilder一道被GC回收了。

同时我们可以看到，如果返回了新对象，则当前容器还可以继续在Append时使用，否则Append方法便会因为m_currentValue为Zero而创建新的容器。不过，从ToString的实现中也可以看出，多次调用ToString方法一定返回新建的对象。这是一种浪费，虽然在一般情况下这不会成为问题，但如果写出这样的代码，便是无端在浪费性能了：

var sb = new StringBuilder();
// ...

for (var i = 0; i < sb.ToString().Length; i++)
{ 
    // ...
}

喔，很容易明白，不是吗？

似乎关于String和StringBuilder对象的一切都差不多暴露在眼前，那么我们离真相也应该已经不远了。不过接下来的东西，还是留在下次评述吧。

刷新页面返回顶部

老赵点滴 - 追求编程之美先做人，再做技术人员，最后做程序员。打造国内最好的.NET技术博客。

重谈字符串连接性能（中）：细节实现

String.Concat为什么这么快

String即Builder

相关文章

About

老赵点滴 - 追求编程之美 先做人，再做技术人员，最后做程序员。打造国内最好的.NET技术博客。

重谈字符串连接性能（中）：细节实现

String.Concat为什么这么快

String即Builder

相关文章

About

老赵点滴 - 追求编程之美先做人，再做技术人员，最后做程序员。打造国内最好的.NET技术博客。