[Golang]字符串拼接方式的性能分析

本文100%由本人（Haoxiang Ma）原创，如需转载请注明出处。

本文写于2019/02/16，基于Go 1.11。
至于其他版本的Go SDK，如有出入请自行查阅其他资料。

Overview

写本文的动机来源于Golang中文社区里一篇有头没尾的帖子《Go语言字符串高效拼接》，里面只提了Golang里面字符串拼接的几种方式，但是在最后却不讲每种方式的性能，也没有给出任何的best practice。本着无聊 + 好奇心，就决定自行写benchmark来测试，再对结果和源码进行分析，试图给出我认为的best practice吧。

性能测试

根据帖子里的内容，在Golang里有5种字符串拼接的方式：

• 直接+号拼接

  func (strs []string) string {
  	s := ""
  	for _, str := range strs {
  		s += str
  	}
  	return s
  }

• fmt.Sprint()拼接

  // fmt拼接
  func ConcatWithFmt(strs []string) string {
  	s := fmt.Sprint(strs)
  	return s
  }

• strings.Join()拼接

  // strings.Join拼接
  func ConcatWithJoin(strs []string) string {
  	s := strings.Join(strs, "")
  	return s
  }

• Buffer拼接

  // bytes.Buffer拼接
  func ConcatWithBuffer(strs []string) string {
  	buf := bytes.Buffer{}
  	for _, str := range strs {
  		buf.WriteString(str)
  	}
  	return buf.String()
  }

• Builder拼接

  // strings.Builder拼接
  func ConcatWithBuilder(strs []string) string {
  	builder := strings.Builder{}
  	for _, str := range strs {
  		builder.WriteString(str)
  	}
  	return builder.String()
  }

为了测试各自的性能，就用Golang自带test模块的benchmark来进行测试。

在测试中，分3组数据，5组测试，即一共3 * 5 = 15次独立测试。其中3组数据是指：

• size = 10K的字符串数组，每个元素均为"hello"
• size = 50K的字符串数组，每个元素均为"hello"
• size = 100K的字符串数组，每个元素均为"hello"

5组测试是指：

• 直接+号拼接，要跑10K、50K、100K的数据
• fmt.Sprint()拼接，要跑10K、50K、100K的数据
• strings.Join()拼接，要跑10K、50K、100K的数据
• Buffer拼接，要跑10K、50K、100K的数据
• Builder拼接，要跑10K、50K、100K的数据

Benchmark代码如下：

package main

import (
	"os"
	"testing"
)

var (
	Strs10K  []string	// 长度为10K的字符串数组
	Strs50K  []string	// 长度为50K的字符串数组
	Strs100K []string	// 长度为100K的字符串数组
	word = "hello"		// 待拼接的字符串
)

const (
	ADD = iota
	BUFFER
	BUILDER
	JOIN
	FMT

	_10K = 10000
	_50K = 50000
	_100K = 100000
)

// preset和teardown
func TestMain(m *testing.M) {
	Strs10K = make([]string, 0, _10K)
	Strs50K = make([]string, 0, _50K)
	Strs100K = make([]string, 0, _100K)

	for i := 0;i < _100K;i++ {
		if (i < _10K) {
			Strs10K = append(Strs10K, word)
			Strs50K = append(Strs50K, word)
		} else if (i < _50K) {
			Strs50K = append(Strs50K, word)
		}
		Strs100K = append(Strs100K, word)
	}

	exitCode := m.Run()
	os.Exit(exitCode)
}

// 测试直接+号拼接
func BenchmarkConcatWithAdd(b *testing.B) {
	b.Run("Concat-10000", GetTestConcat(Strs10K, ADD))
	b.Run("Concat-50000", GetTestConcat(Strs50K, ADD))
	b.Run("Concat-100000", GetTestConcat(Strs100K, ADD))
}

// 测试bytes.Buffer拼接
func BenchmarkConcatWithBuffer(b *testing.B) {
	b.Run("Concat-10000", GetTestConcat(Strs10K, BUFFER))
	b.Run("Concat-50000", GetTestConcat(Strs50K, BUFFER))
	b.Run("Concat-100000", GetTestConcat(Strs100K, BUFFER))
}

// 测试strings.Builder拼接
func BenchmarkConcatWithBuilder(b *testing.B) {
	b.Run("Concat-10000", GetTestConcat(Strs10K, BUILDER))
	b.Run("Concat-50000", GetTestConcat(Strs50K, BUILDER))
	b.Run("Concat-100000", GetTestConcat(Strs100K, BUILDER))
}

// 测试strings.Join拼接
func BenchmarkConcatWithJoin(b *testing.B) {
	b.Run("Concat-10000", GetTestConcat(Strs10K, JOIN))
	b.Run("Concat-50000", GetTestConcat(Strs50K, JOIN))
	b.Run("Concat-100000", GetTestConcat(Strs100K, JOIN))
}

// 测试fmt拼接
func BenchmarkConcatWithFmt(b *testing.B) {
	b.Run("Concat-10000", GetTestConcat(Strs10K, FMT))
	b.Run("Concat-50000", GetTestConcat(Strs50K, FMT))
	b.Run("Concat-100000", GetTestConcat(Strs100K, FMT))
}

// 根据拼接类型（testType），返回对应的测试方法
func GetTestConcat(strs []string, testType int) func(b *testing.B) {
	concatFunc := func([]string) string {return ""}
	switch testType {
	case ADD:
		concatFunc = ConcatWithAdd
	case BUFFER:
		concatFunc = ConcatWithBuffer
	case BUILDER:
		concatFunc = ConcatWithBuilder
	case JOIN:
		concatFunc = ConcatWithJoin
	case FMT:
		concatFunc = ConcatWithFmt
	}

	return func(b *testing.B) {
		for i := 0;i < b.N;i++ {
			concatFunc(strs)
		}
	}
}

经过测试（go test -bench=. -benchmem），结果如下：

......
  4 BenchmarkConcatWithAdd/Concat-10000-4                 20      57050217 ns/op    270493320 B/op      9999 allocs/op
  5 BenchmarkConcatWithAdd/Concat-50000-4                  2     937660008 ns/op    6435464656 B/op    49999 allocs/op
  6 BenchmarkConcatWithAdd/Concat-100000-4                 1    3748714961 ns/op    25388918224 B/op       99999 allocs/op
  7 BenchmarkConcatWithBuffer/Concat-10000-4           10000        138797 ns/op      209376 B/op         12 allocs/op
  8 BenchmarkConcatWithBuffer/Concat-50000-4            3000        481466 ns/op      840160 B/op         14 allocs/op
  9 BenchmarkConcatWithBuffer/Concat-100000-4           2000        966963 ns/op     1659360 B/op         15 allocs/op
 10 BenchmarkConcatWithBuilder/Concat-10000-4          10000        103924 ns/op      227320 B/op         21 allocs/op
 11 BenchmarkConcatWithBuilder/Concat-50000-4           3000        495917 ns/op     1431545 B/op         28 allocs/op
 12 BenchmarkConcatWithBuilder/Concat-100000-4          2000        891950 ns/op     2930682 B/op         31 allocs/op
大专栏  [Golang]字符串拼接方式的性能分析/> 13 BenchmarkConcatWithJoin/Concat-10000-4             10000        106288 ns/op      114688 B/op          2 allocs/op
 14 BenchmarkConcatWithJoin/Concat-50000-4              3000        505209 ns/op      507904 B/op          2 allocs/op
 15 BenchmarkConcatWithJoin/Concat-100000-4             2000        990317 ns/op     1015808 B/op          2 allocs/op
 16 BenchmarkConcatWithFmt/Concat-10000-4               1000       1293589 ns/op      227716 B/op      10002 allocs/op
 17 BenchmarkConcatWithFmt/Concat-50000-4                200       6260637 ns/op     1131960 B/op      50003 allocs/op
 18 BenchmarkConcatWithFmt/Concat-100000-4               100      12005780 ns/op     2499702 B/op     100006 allocs/op
 ......

可以看出

• 运行速度上，Builder、Buffer、Join的速度属于同一数量级，绝对值也差不了太多；fmt要比它们一个数量级；直接+号拼接是最慢的。
• 内存分配上，Join表现最优秀，Buffer次之，Builder第三；而fmt和直接+号拼接最差，要执行很多次内存分配操作。

源码分析

• 速度&内存分配都很优秀的strings.Join()

  func Join(a []string, sep string) string {
  	// 专门为短数组拼接做的优化
  	// 详情查阅golang.org/issue/6714
  	switch len(a) {
  	case 0:
  		return ""
  	case 1:
  		return a[0]
  	case 2:
  		return a[0] + sep + a[1]
  	case 3:
  		return a[0] + sep + a[1] + sep + a[2]
  	}
  
  	// 计算总共要插入多长的分隔符，n = 分隔符总长
  	n := len(sep) * (len(a) - 1)
  
  	// 遍历待拼接的数组，逐个叠加字符串的长度
  	// 最后n = 分隔符总长 + 所有字符串的总长 = 拼接结果的总长
  	for i := 0; i < len(a); i++ {
  		n += len(a[i])
  	}
  
  	// 一次性分配n byte的内存空间，并且把第一个字符串拷贝到slice的头部
  	b := make([]byte, n)
  	bp := copy(b, a[0])
  
  	// 从下标为1开始，调用原生的copy函数
  	// 逐个把分隔符&字符串拷贝到slice里对应的位置
  	for _, s := range a[1:] {
  		bp += copy(b[bp:], sep)
  		bp += copy(b[bp:], s)
  	}
  
  	// 最后将byte slice强转为string，返回
  	return string(b)
  }

  可以看出strings.Join()为什么表现如此优秀，主要原因是只有1次的显式内存分配（b := make([]byte, n)）和1次隐式内存分配（return string(b)），不需要在拼接过程中反复多次分配内存，挪动内存里的数据，减少了很多内存管理的消耗。

• 略差一筹的bytes.Buffer.WriteString()

  // 尝试扩容n个单位
  func (b *Buffer) tryGrowByReslice(n int) (int, bool) {
  	// 如果底层slice的剩余空间 >= n个单位，就不需要重新分配内存
  	// 而是reslice，把底层slice的cap限定在l + n
  	if l := len(b.buf); n <= cap(b.buf)-l {
  		b.buf = b.buf[:l+n]
  		return l, true
  	}
  
  	// 如果底层slice的剩余空间不足n个单位，放弃reslice
  	// 说明需要重新分配内存，而不是reslice那么简单了
  	return 0, false
  }
  
  // 扩容n个单位
  func (b *Buffer) grow(n int) int {
  	m := b.Len()
  
  	// 边界情况，空slice，先把一些属性reset掉
  	if m == 0 && b.off != 0 {
  		b.Reset()
  	}
  
  	// 先试试不真正分配空间，通过reslice来“扩容”
  	if i, ok := b.tryGrowByReslice(n); ok {
  		return i
  	}
  
  	// bootstrap是一个长度为64的slice，在buffer对象初始化时，
  	// bootstrap就已经分配好了，如果n小于bootstrap长度，
  	// 可以利用bootstrap slice来reslice，不需要重新分配内存空间
  	if b.buf == nil && n <= len(b.bootstrap) {
  		b.buf = b.bootstrap[:n]
  		return 0
  	}
  
  	// 上述几种情况都无法满足
  	c := cap(b.buf)
  	if n <= c/2-m {
  		// 理解为m + n <= c/2比较好
  		// 如果扩容后的长度（m + n）比c/2要小，说明当前还有一大堆可用的空间
  		// 直接reslice，以b.off打头
  		copy(b.buf, b.buf[b.off:])
  	} else if c > maxInt-c-n {
  		// c + c + n > maxInt，申请扩容n个单位太多了，不可接受
  		panic(ErrTooLarge)
  	} else {
  		// 当前剩余的空间不太够了，重新分配内存，长度为c + c + n
  		buf := makeSlice(2*c + n)
  		copy(buf, b.buf[b.off:])
  		b.buf = buf
  	}
  	// Restore b.off and len(b.buf).
  	b.off = 0
  	b.buf = b.buf[:m+n]
  	return m
  }
  
  // 拼接的方法
  func (b *Buffer) WriteString(s string) (n int, err error) {
  	b.lastRead = opInvalid
  
  	// 先尝试reslice得到len(s)个单位的空间
  	m, ok := b.tryGrowByReslice(len(s))
  	if !ok {
  		// 无法通过reslice得到空间，直接粗暴地申请grow
  		m = b.grow(len(s))
  	}
  	return copy(b.buf[m:], s), nil
  }

  为什么bytes.Buffer.WriteString()性能比Join差呢，其实也是内存分配策略惹的祸。在Join里只有两次内存空间申请的操作，而Buffer里可能会有很多次。具体来说就是buf := makeSlice(2*c + n)这一句，每次重申请只申请2 * c + n的空间，用完了就要再申请2 * c + n。当拼接的数据项很多，每次申请的空间也就2 * c + n，很快就用完了，又要再重新申请，所以造成了性能不是很高。

• 略差一筹的strings.Builder()

  func (b *Builder) WriteString(s string) (int, error) {
  	b.copyCheck()
  	b.buf = append(b.buf, s...)
  	return len(s), nil
  }

  代码很简洁，就是最直白的slice append，一时append一时爽，一直append一直爽。所以当底层slice的可用空间不足，就会在append里一直申请新的内存空间。跟bytes.Buffer不同的是，这里并没有自己管理“扩容”的逻辑，而是交由原生的append函数去管理。

• 最差劲的fmt.Sprint()

  type buffer []byte
  
  type pp struct {
  	buf buffer
  	......
  }
  
  func Sprint(a ...interface{}) string {
  	p := newPrinter()
  	p.doPrint(a)
  	s := string(p.buf)
  	p.free()
  	return s
  }

  printer里的核心数据结构就是buf，而buf其实就是一个[]byte，所以给buf不停地拼接字符串，空间不够了又继续开辟新的内存空间，所以性能低下。

总结

实际上，只有当拼接的字符串非常非常多的时候，才需要纠结性能。像本文里动辄拼接10K、50K、100K个字符串的情况在实际业务中应该是很少很少的。

如果实在要纠结性能，参考以下几点

• Join的速度最好，但是不至于完爆Builder和Buffer。三者的速度属于同一数量级。fmt和直接+号拼接速度最慢。
• Join的内存分配策略最好，内存分配次数最少；Builder和Buffer的内存分配策略还算可以，类似于线性增长；fmt和直接+号拼接的内存分配策略最差。