我們首先來了解一下Go
語言中string
類型的結構定義,先來看一下官方定義:
// string is the set of all strings of 8-bit bytes, conventionally but not
// necessarily representing UTF-8-encoded text. A string may be empty, but
// not nil. Values of string type are immutable.
type string string
string
是一個8
位字節的集合,通常但不一定代表UTF-8編碼的文本。string可以為空,但是不能為nil。string的值是不能改變的。
string
類型本質也是一個結構體,定義如下:
type stringStruct struct {
str unsafe.Pointer
len int
}
stringStruct
和slice
還是很相似的,str
指針指向的是某個數組的首地址,len
代表的就是數組長度。怎么和slice
這么相似,底層指向的也是數組,是什么數組呢?我們看看他在實例化時調用的方法:
//go:nosplit
func gostringnocopy(str *byte) string {
ss := stringStruct{str: unsafe.Pointer(str), len: findnull(str)}
s := *(*string)(unsafe.Pointer(&ss))
return s
}
入參是一個byte
類型的指針,從這我們可以看出string
類型底層是一個byte
類型的數組,所以我們可以畫出這樣一個圖片:
圖片
string
類型本質上就是一個byte
類型的數組,在Go
語言中string
類型被設計為不可變的,不僅是在Go
語言,其他語言中string
類型也是被設計為不可變的,這樣的好處就是:在並發場景下,我們可以在不加鎖的控制下,多次使用同一字符串,在保證高效共享的情況下而不用擔心安全問題。
string
類型雖然是不能更改的,但是可以被替換,因為stringStruct
中的str
指針是可以改變的,只是指針指向的內容是不可以改變的,也就說每一個更改字符串,就需要重新分配一次內存,之前分配的空間會被gc
回收。
關於string
類型的知識點就描述這么多,方便我們后面分析字符串拼接。
字符串拼接的6種方式及原理
原生拼接方式"+"
Go
語言原生支持使用+
操作符直接對兩個字符串進行拼接,使用例子如下:
var s string
s += "asong"
s += "真帥"
這種方式使用起來最簡單,基本所有語言都有提供這種方式,使用+
操作符進行拼接時,會對字符串進行遍歷,計算並開辟一個新的空間來存儲原來的兩個字符串。
字符串格式化函數fmt.Sprintf
Go
語言中默認使用函數fmt.Sprintf
進行字符串格式化,所以也可使用這種方式進行字符串拼接:
str := "asong"
str = fmt.Sprintf("%s%s", str, str)
fmt.Sprintf
實現原理主要是使用到了反射,具體源碼分析因為篇幅的原因就不在這里詳細分析了,看到反射,就會產生性能的損耗,你們懂得!!!
Strings.builder
Go
語言提供了一個專門操作字符串的庫strings
,使用strings.Builder
可以進行字符串拼接,提供了writeString
方法拼接字符串,使用方式如下:
var builder strings.Builder
builder.WriteString("asong")
builder.String()
strings.builder
的實現原理很簡單,結構如下:
type Builder struct {
addr *Builder // of receiver, to detect copies by value
buf []byte // 1
}
addr
字段主要是做copycheck
,buf
字段是一個byte
類型的切片,這個就是用來存放字符串內容的,提供的writeString()
方法就是像切片buf
中追加數據:
func (b *Builder) WriteString(s string) (int, error) {
b.copyCheck()
b.buf = append(b.buf, s...)
return len(s), nil
}
提供的String
方法就是將[]]byte
轉換為string
類型,這里為了避免內存拷貝的問題,使用了強制轉換來避免內存拷貝:
func (b *Builder) String() string {
return *(*string)(unsafe.Pointer(&b.buf))
}
bytes.Buffer
因為string
類型底層就是一個byte
數組,所以我們就可以Go
語言的bytes.Buffer
進行字符串拼接。bytes.Buffer
是一個一個緩沖byte
類型的緩沖器,這個緩沖器里存放着都是byte
。使用方式如下:
buf := new(bytes.Buffer)
buf.WriteString("asong")
buf.String()
bytes.buffer
底層也是一個[]byte
切片,結構體如下:
type Buffer struct {
buf []byte // contents are the bytes buf[off : len(buf)]
off int // read at &buf[off], write at &buf[len(buf)]
lastRead readOp // last read operation, so that Unread* can work correctly.
}
因為bytes.Buffer
可以持續向Buffer
尾部寫入數據,從Buffer
頭部讀取數據,所以off
字段用來記錄讀取位置,再利用切片的cap
特性來知道寫入位置,這個不是本次的重點,重點看一下WriteString
方法是如何拼接字符串的:
func (b *Buffer) WriteString(s string) (n int, err error) {
b.lastRead = opInvalid
m, ok := b.tryGrowByReslice(len(s))
if !ok {
m = b.grow(len(s))
}
return copy(b.buf[m:], s), nil
}
切片在創建時並不會申請內存塊,只有在往里寫數據時才會申請,首次申請的大小即為寫入數據的大小。如果寫入的數據小於64字節,則按64字節申請。采用動態擴展slice
的機制,字符串追加采用copy
的方式將追加的部分拷貝到尾部,copy
是內置的拷貝函數,可以減少內存分配。
但是在將[]byte
轉換為string
類型依舊使用了標准類型,所以會發生內存分配:
func (b *Buffer) String() string {
if b == nil {
// Special case, useful in debugging.
return "<nil>"
}
return string(b.buf[b.off:])
}
strings.join
Strings.join
方法可以將一個string
類型的切片拼接成一個字符串,可以定義連接操作符,使用如下:
baseSlice := []string{"asong", "真帥"}
strings.Join(baseSlice, "")
strings.join
也是基於strings.builder
來實現的,代碼如下:
func Join(elems []string, sep string) string {
switch len(elems) {
case 0:
return ""
case 1:
return elems[0]
}
n := len(sep) * (len(elems) - 1)
for i := 0; i < len(elems); i++ {
n += len(elems[i])
}
var b Builder
b.Grow(n)
b.WriteString(elems[0])
for _, s := range elems[1:] {
b.WriteString(sep)
b.WriteString(s)
}
return b.String()
}
唯一不同在於在join
方法內調用了b.Grow(n)
方法,這個是進行初步的容量分配,而前面計算的n的長度就是我們要拼接的slice的長度,因為我們傳入切片長度固定,所以提前進行容量分配可以減少內存分配,很高效。
切片append
因為string
類型底層也是byte
類型數組,所以我們可以重新聲明一個切片,使用append
進行字符串拼接,使用方式如下:
buf := make([]byte, 0)
base = "asong"
buf = append(buf, base...)
string(base)
如果想減少內存分配,在將[]byte
轉換為string
類型時可以考慮使用強制轉換。
Benchmark對比
上面我們總共提供了6種方法,原理我們基本知道了,那么我們就使用Go
語言中的Benchmark
來分析一下到底哪種字符串拼接方式更高效。我們主要分兩種情況進行分析:
- 少量字符串拼接
- 大量字符串拼接
因為代碼量有點多,下面只貼出分析結果,詳細代碼已經上傳github
:https://github.com/asong2020/Golang_Dream/tree/master/code_demo/string_join
我們先定義一個基礎字符串:
var base = "123456789qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASFGHJKLZXCVBNM"
少量字符串拼接的測試我們就采用拼接一次的方式驗證,base拼接base,因此得出benckmark結果:
goos: darwin
goarch: amd64
pkg: asong.cloud/Golang_Dream/code_demo/string_join/once
cpu: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
BenchmarkSumString-16 21338802 49.19 ns/op 128 B/op 1 allocs/op
BenchmarkSprintfString-16 7887808 140.5 ns/op 160 B/op 3 allocs/op
BenchmarkBuilderString-16 27084855 41.39 ns/op 128 B/op 1 allocs/op
BenchmarkBytesBuffString-16 9546277 126.0 ns/op 384 B/op 3 allocs/op
BenchmarkJoinstring-16 24617538 48.21 ns/op 128 B/op 1 allocs/op
BenchmarkByteSliceString-16 10347416 112.7 ns/op 320 B/op 3 allocs/op
PASS
ok asong.cloud/Golang_Dream/code_demo/string_join/once 8.412s
大量字符串拼接的測試我們先構建一個長度為200的字符串切片:
var baseSlice []string
for i := 0; i < 200; i++ {
baseSlice = append(baseSlice, base)
}
然后遍歷這個切片不斷的進行拼接,因為可以得出benchmark
:
goos: darwin
goarch: amd64
pkg: asong.cloud/Golang_Dream/code_demo/string_join/muliti
cpu: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
BenchmarkSumString-16 7396 163612 ns/op 1277713 B/op 199 allocs/op
BenchmarkSprintfString-16 5946 202230 ns/op 1288552 B/op 600 allocs/op
BenchmarkBuilderString-16 262525 4638 ns/op 40960 B/op 1 allocs/op
BenchmarkBytesBufferString-16 183492 6568 ns/op 44736 B/op 9 allocs/op
BenchmarkJoinstring-16 398923 3035 ns/op 12288 B/op 1 allocs/op
BenchmarkByteSliceString-16 144554 8205 ns/op 60736 B/op 15 allocs/op
PASS
ok asong.cloud/Golang_Dream/code_demo/string_join/muliti 10.699s
結論
通過兩次benchmark
對比,我們可以看到
- 當進行少量字符串拼接時,直接使用
+
操作符進行拼接字符串,效率還是挺高的,但是當要拼接的字符串數量上來時,+
操作符的性能就比較低了; - 函數
fmt.Sprintf
還是不適合進行字符串拼接,無論拼接字符串數量多少,性能損耗都很大,還是老老實實做他的字符串格式化就好了; strings.Builder
無論是少量字符串的拼接還是大量的字符串拼接,性能一直都能穩定,這也是為什么Go
語言官方推薦使用strings.builder
進行字符串拼接的原因,在使用strings.builder
時最好使用Grow
方法進行初步的容量分配,觀察strings.join
方法的benchmark就可以發現,因為使用了grow
方法,提前分配好內存,在字符串拼接的過程中,不需要進行字符串的拷貝,也不需要分配新的內存,這樣使用strings.builder
性能最好,且內存消耗最小。bytes.Buffer
方法性能是低於strings.builder
的,bytes.Buffer
轉化為字符串時重新申請了一塊空間,存放生成的字符串變量,不像strings.buidler
這樣直接將底層的[]byte
轉換成了字符串類型返回,這就占用了更多的空間。
同步最后分析的結論:
無論什么情況下使用strings.builder
進行字符串拼接都是最高效的,不過要主要使用方法,記得調用grow
進行容量分配,才會高效。strings.join
的性能約等於strings.builder
,在已經字符串slice的時候可以使用,未知時不建議使用,構造切片也是有性能損耗的;如果進行少量的字符串拼接時,直接使用+
操作符是最方便也是性能最高的,可以放棄strings.builder
的使用。
綜合對比性能排序:
strings.join` ≈ `strings.builder` > `bytes.buffer` > `[]byte`轉換`string` > "+" > `fmt.sprintf
總結
本文我們針對6
種字符串的拼接方式進行介紹,並通過benckmark
對比了效率,無論什么時候使用strings.builder
都不會錯,但是在少量字符串拼接時,直接+
也就是更優的方式,具體業務場景具體分析,不要一概而論