[[402519]]

本文轉(zhuǎn)載自微信公眾號(hào)「架構(gòu)技術(shù)漫談」，作者橙子。轉(zhuǎn)載本文請(qǐng)聯(lián)系架構(gòu)技術(shù)漫談公眾號(hào)。

不久前，因?yàn)橐恍┰?，我們決定用 Go 語(yǔ)言對(duì)一個(gè) Java 項(xiàng)目進(jìn)行重構(gòu)。這個(gè)項(xiàng)目的業(yè)務(wù)非常簡(jiǎn)單，在實(shí)現(xiàn)簡(jiǎn)單業(yè)務(wù)的簡(jiǎn)單功能時(shí)，需要將幾組短字符串按順序拼接成一個(gè)長(zhǎng)字符串。毋庸置疑，使用 + 操作符，是常用的字符串拼接方法，這在很多編程語(yǔ)言中都適用，Go 也不例外。

功能重構(gòu)很快完成了，但在代碼 review 環(huán)節(jié)時(shí)，對(duì)新語(yǔ)言的好奇心頻頻冒出，Go 語(yǔ)言中是否有其他更為高級(jí)或者靈活的方法呢?經(jīng)過(guò)一番調(diào)研嘗試，初步得出使用 strings.Builder 是性能最優(yōu)的結(jié)論，于是，決定用它替換 + 操作符，并部署到線上。

幾個(gè)月后，該項(xiàng)目在原基礎(chǔ)上需求有所增加。再次面對(duì)該代碼，心情也發(fā)生了變化，使用 strings.Builder 固然可行，但它需要三行代碼，相比之下，用 + 操作符一行代碼便能實(shí)現(xiàn)。在簡(jiǎn)潔性和高效性之間，該如何抉擇呢?Go 語(yǔ)言中，是否有魚和熊掌兼得的方法?

抱著這樣的心思，我總結(jié)出 Go 語(yǔ)言中至少有 6 種關(guān)于字符串的拼接方式。但新問(wèn)題也隨之產(chǎn)生了，為何 Go 語(yǔ)言支持如此多種拼接方式?每種方式的存在，其背后的原因和邏輯又是什么呢?

讓我們先分兩種常用場(chǎng)景、兩種字符串長(zhǎng)度進(jìn)行對(duì)比看看。

一、不同情景下的效率測(cè)試

待拼接字符串長(zhǎng)度、次數(shù)已知，可一次完成字符串拼接，測(cè)試結(jié)果如下：

32 字節(jié)以下。

超過(guò) 32 字節(jié)，未超過(guò) 64 字節(jié)。+ 操作符發(fā)生了一次內(nèi)存分配，但效率依然很高。bytes.Buffer 高于 strings.Builder。

64 字節(jié)以上。+ 操作符優(yōu)勢(shì)依然明顯，strings.Join() 也不甘示弱。

待拼接字符串長(zhǎng)度、次數(shù)未知，需要循環(huán)追加完成拼接操作，測(cè)試結(jié)果如下：

32 字節(jié)以下。+ 每次拼接都會(huì)生成新字符串，導(dǎo)致大量的字符串創(chuàng)建、替代。

超過(guò) 32 字節(jié)，未超過(guò) 64 字節(jié)。bytes.Buffer 發(fā)生 2 次內(nèi)存分配。

64 字節(jié)以上。bytes.Buffer 優(yōu)勢(shì)已然不再， strings.Builder 一騎絕塵。不過(guò)，這似乎還不是最終的結(jié)果。

大量字符串拼接，終于要使出 strings.Builder 的必殺器 Grow() 了，bytes.Buffer 也有 Grow() 方法，但似乎作用不大。

二、原理分析

從上面的測(cè)試結(jié)果可以看出，在不同情況下，每種拼接方式的效率都不同，為什么會(huì)這樣呢?那就得從它們的拼接原理說(shuō)起。

+ 操作符，也叫級(jí)聯(lián)符。它使用簡(jiǎn)單、應(yīng)用廣泛。

res := "發(fā)" + "發(fā)" 

拼接過(guò)程：

1.編譯器將字符串轉(zhuǎn)換成字符數(shù)組后調(diào)用 runtime/string.go 的 concatstrings() 函數(shù)

2.在函數(shù)內(nèi)遍歷字符數(shù)組，得到總長(zhǎng)度

3.如果字符數(shù)組總長(zhǎng)度未超過(guò)預(yù)留 buf(32字節(jié))，使用預(yù)留，反之，生成新的字符數(shù)組，根據(jù)總長(zhǎng)度一次性分配內(nèi)存空間

4.將字符串逐個(gè)拷貝到新數(shù)組，并銷毀舊數(shù)組

+= 追加操作符，與 + 操作符相同，也是通過(guò) runtime/string.go的concatstrings() 函數(shù)實(shí)現(xiàn)拼接，區(qū)別是它通常用于循環(huán)中往字符串末尾追加，每追加一次，生成一個(gè)新的字符串替代舊的，效率極低。

res := "發(fā)" 
  res += "發(fā)" 

拼接過(guò)程：

1.同上

bytes.Buffer ，在 Golang 1.10 之前，它是循環(huán)中往末尾追加效率最高的方法，尤其是當(dāng)拼接的字符串?dāng)?shù)量較大時(shí)。

var b bytes.Buffer    // 創(chuàng)建一個(gè) buffer 
b.WriteString("發(fā)")   // 將字符串追加到buffer上  
b.WriteString("發(fā)")    
b.String()            // 取出字符串并返回 

拼接過(guò)程：

1.創(chuàng)建 []byte ，用于緩存需要拼接的字符串

2.首次使用 WriteString() 填充字符串時(shí)，由于字節(jié)數(shù)組容量為 0 ，最少會(huì)發(fā)生 1 次內(nèi)存分配

3.待拼接字符串長(zhǎng)度小于 64 字節(jié)，make 一個(gè)長(zhǎng)度為字符串總長(zhǎng)度，容量為 64 字節(jié)的新數(shù)組

4.待拼接字符串超過(guò) 64 字節(jié)時(shí)動(dòng)態(tài)擴(kuò)容，按 2* 當(dāng)前容量 + 待拼接字符長(zhǎng)度 make 新字節(jié)數(shù)組

5.將字節(jié)數(shù)組轉(zhuǎn)換成 string 類型返回

strings.Builder 在 Golang 1.10 更新后，替代了byte.Buffer，成為號(hào)稱效率最高的拼接方法。

var b strings.Builder   
 b.WriteString("發(fā)")    
 b.WriteString("發(fā)") 
 b.String() 

拼接過(guò)程：

1.創(chuàng)建 []byte，用于緩存需要拼接的字符串

2.通過(guò) append 將數(shù)據(jù)填充到前面創(chuàng)建的 []byte 中

3.append 時(shí)，如果字符串超過(guò)初始容量 8 且小于 1024 字節(jié)時(shí)，按乘以 2 的容量創(chuàng)建新的字節(jié)數(shù)組，超過(guò) 1024 字節(jié)時(shí)，按 1/4 增加

4.將老數(shù)據(jù)復(fù)制到新創(chuàng)建的字節(jié)數(shù)組中 5.追加新數(shù)據(jù)并返回

strings.Join() 主要適用于以指定分隔符方式連接成一個(gè)新字符串，分隔符可以為空，在字符串一次拼接操作中，性能僅次于 + 操作符。

strings.Join([]string{"發(fā)", "發(fā)"}, "") 

拼接過(guò)程：

1.接收的是一個(gè)字符切片

2.遍歷字符切片得到總長(zhǎng)度，據(jù)此通過(guò) builder.Grow 分配內(nèi)存

3.底層使用了 strings.Builder，每使用一次 strings.Join() ，都會(huì)創(chuàng)建新的 builder 對(duì)象

fmt.Sprintf()，返回使用 format 格式化的參數(shù)。除了字符串拼接，函數(shù)內(nèi)還有很多格式方面的判斷，性能不高，但它可以拼接多種類型，字符串或數(shù)字等。

fmt.Sprintf("str1 = %v,str2 = %v", "發(fā)", "發(fā)") 

拼接過(guò)程:

1.創(chuàng)建對(duì)象

2.字符串格式化操作

3.將格式化后的字符串通過(guò) append 方式放到[] byte 中

4.最后將字節(jié)數(shù)組轉(zhuǎn)換成 string 返回

三、結(jié)論

在待拼接字符串確定，可一次完成字符串拼接的情況下，推薦使用 + 操作符，即便 strings.Builder 用 Grow() 方法預(yù)先擴(kuò)容，其性能也是不如 + 操作符的，另外，Grow()也不可設(shè)置過(guò)大。

在拼接字符串不確定、需要循環(huán)追加字符串時(shí)，推薦使用 strings.Builder。但在使用時(shí)，必須使用 Grow() 預(yù)先擴(kuò)容，否則性能不如 strings.Join()。