Go 面試題：string 是線程安全的嗎？
大家好，我是煎魚。
之前在某知名平臺(tái)看到大家在交流 Go 崗位相關(guān)的面試題，其中有一道引起了大家的一些討論，勾起被八股文的深深回憶。
面試題如下：
圖片
如標(biāo)題所示，原題是：Go 中的 string 賦值是線程安全的嗎？
我們可以一起先想想答案，看看中不中。
線程安全是什么
線程安全是指在多線程環(huán)境下，程序的執(zhí)行能夠正確地處理多個(gè)線程并發(fā)訪問共享數(shù)據(jù)的情況，保證程序的正確性和可靠性。
圖片
能被稱之為：線程安全，需要在多個(gè)線程同時(shí)訪問共享數(shù)據(jù)時(shí)，滿足如下幾個(gè)條件：
- 不會(huì)出現(xiàn)數(shù)據(jù)競(jìng)爭(zhēng)（data race）：多個(gè)線程同時(shí)對(duì)同一數(shù)據(jù)進(jìn)行讀寫操作，導(dǎo)致數(shù)據(jù)不一致或未定義的行為。
- 不會(huì)出現(xiàn)死鎖（deadlock）：多個(gè)線程互相等待對(duì)方釋放資源而無法繼續(xù)執(zhí)行的情況。
- 不會(huì)出現(xiàn)饑餓（starvation）：某個(gè)線程因?yàn)橘Y源分配不公而無法得到執(zhí)行的情況。
string 線程安全
需要有一個(gè)基礎(chǔ)了解，對(duì)于 string 類型，運(yùn)行時(shí)表現(xiàn)對(duì)照是 StringHeader 結(jié)構(gòu)體。
如下：
type StringHeader struct {
Data uintptr
Len int
}- Data：存放指針，其指向具體的存儲(chǔ)數(shù)據(jù)的內(nèi)存區(qū)域。
- Len：字符串的長(zhǎng)度。
在了解前置知識(shí)后，接下來進(jìn)入到實(shí)踐環(huán)境。看看在 Go 里 string 類型的變量，做并發(fā)賦值到底是否線程安全。
案例一：并發(fā)訪問
我們先看第一個(gè)案例，多個(gè) goroutine 中并發(fā)訪問同一個(gè) string 變量的場(chǎng)景。如下代碼：
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
str := "腦子進(jìn)煎魚了"
for i := 0; i < 5; i++ {
wg.Add(1)
go func() {
defer wg.Done()
fmt.Println(str)
}()
}
wg.Wait()
}輸出結(jié)果：
腦子進(jìn)煎魚了
腦子進(jìn)煎魚了
腦子進(jìn)煎魚了
腦子進(jìn)煎魚了
腦子進(jìn)煎魚了在上面的例子中，我們定義了一個(gè) string 變量 str，然后啟動(dòng)了 5 個(gè) goroutine，每個(gè) goroutine 都會(huì)輸出 str 的值。由于 str 是不可變類型，因此在多個(gè) goroutine 中并發(fā)訪問它是安全的。
可能有同學(xué)疑惑不可變類型是什么？
不可變類型，指的是一種不能被修改的數(shù)據(jù)類型，也稱為值類型（value type）。不可變類型在創(chuàng)建后其值不能被改變，任何對(duì)它的修改操作都會(huì)返回一個(gè)新的值，而不會(huì)改變?cè)械闹怠?/p>
案例二：并發(fā)寫入
第一個(gè)案例看起來沒什么問題。我們?cè)倏吹诙€(gè)案例，針對(duì)多個(gè) goroutine 并發(fā)寫入的場(chǎng)景來進(jìn)行驗(yàn)證。
如下代碼：
func main() {
var wg sync.WaitGroup
str := "腦子進(jìn)煎魚了"
for i := 0; i < 5; i++ {
wg.Add(1)
go func() {
defer wg.Done()
str += "！" // 修改 str 變量
fmt.Println(str)
}()
}
wg.Wait()
}輸出結(jié)果：
腦子進(jìn)煎魚了！
腦子進(jìn)煎魚了！！
腦子進(jìn)煎魚了！！！
腦子進(jìn)煎魚了！！！！
腦子進(jìn)煎魚了！！！！！看起來沒什么問題，還是正常的拼接結(jié)果，輸出的順序也完全沒有問題的樣子。（大霧）
我們?cè)俣噙\(yùn)行幾次。再看看輸出結(jié)果：
// demo1
腦子進(jìn)煎魚了！
腦子進(jìn)煎魚了！！
腦子進(jìn)煎魚了！！！
腦子進(jìn)煎魚了！！！
腦子進(jìn)煎魚了！！！
// demo2
腦子進(jìn)煎魚了！
腦子進(jìn)煎魚了！！！
腦子進(jìn)煎魚了！！
腦子進(jìn)煎魚了！！！！！
腦子進(jìn)煎魚了！！！！在上面的例子中，我們?cè)诿總€(gè) goroutine 中向 str 變量中添加了一個(gè)感嘆號(hào)。由于多個(gè) goroutine 同時(shí)修改了 str 變量，因此可能會(huì)出現(xiàn)數(shù)據(jù)競(jìng)爭(zhēng)的情況。
我們會(huì)發(fā)現(xiàn)程序輸出結(jié)果會(huì)出現(xiàn)亂序或不一致的情況，可以確認(rèn) string 類型變量在多個(gè) goroutine 中是不安全的。
要警惕這種場(chǎng)景，在實(shí)際業(yè)務(wù)代碼中，常有人前人留 BUG，后人因此翻車。主打一個(gè)熬夜查和修 BUG，分分鐘還得洗臟數(shù)據(jù)。
string 實(shí)現(xiàn)線程安全
使用互斥鎖
要實(shí)現(xiàn) string 類型變量的線程安全，第一種方式：使用互斥鎖（Mutex）來保護(hù)共享變量，確保同一時(shí)間只有一個(gè) goroutine 可以訪問它。下面是一個(gè)改造后的例子。
如下代碼：
func main() {
var wg sync.WaitGroup
var mu sync.Mutex // 定義一個(gè)互斥鎖
str := "煎魚"
for i := 0; i < 5; i++ {
wg.Add(1)
go func() {
defer wg.Done()
mu.Lock() // 加鎖
str += "！"
fmt.Println(str)
mu.Unlock() // 解鎖
}()
}
wg.Wait()
}輸出結(jié)果：
煎魚！
煎魚！！
煎魚！！！
煎魚！！！！
煎魚！！！！！在上面的例子中，我們使用了 sync 包中的 Mutex 類型來定義一個(gè)互斥鎖 mu。在每個(gè) goroutine 中，我們先使用 mu.Lock() 方法來加鎖，確保同一時(shí)間只有一個(gè) goroutine 可以訪問 str 變量。
再修改 str 變量的值并輸出，最后使用 mu.Unlock() 方法來解鎖，讓其他 goroutine 可以繼續(xù)訪問 str 變量。
需要注意，互斥鎖會(huì)帶來一些性能上的開銷，兩全難齊美。
使用 atomic 包
第二種方案是使用 atomic 包來實(shí)現(xiàn)原子操作，如下代碼：
func main() {
var wg sync.WaitGroup
var str atomic.Value // 定義一個(gè)原子變量
str.Store("hello, world")
for i := 0; i < 5; i++ {
wg.Add(1)
go func() {
defer wg.Done()
oldStr := str.Load().(string) // 讀取原子變量的值
newStr := oldStr + "!"
str.Store(newStr) // 寫入原子變量的值
fmt.Println(newStr)
}()
}
wg.Wait()
}這樣子也可以保證 string 類型變量的原子操作。但在現(xiàn)實(shí)場(chǎng)景下，仍然無法解決多 goroutine 導(dǎo)致的競(jìng)態(tài)條件（race condition）。
也就是存在多個(gè) goroutine 并發(fā)取到的變量值都是一樣的，得到的結(jié)果還是不固定的，最終還是要用 Mutex 或者 RWMutex 鎖來做共享變量保護(hù)。
這兩者沒有絕對(duì)的好壞，但需要分清楚你的使用場(chǎng)景，決定用鎖還是 atomic，又或是其他邏輯上的調(diào)整。
總結(jié)
在前面我們有把 StringHeader 結(jié)構(gòu)體讓大家看看，其實(shí)很明顯是不支持線程安全的。平白無故每個(gè)類型都去支持線程安全的話，會(huì)增加很多開銷。
絕大多數(shù)的情況下，你可以默認(rèn)任何數(shù)據(jù)類型的變量賦值都不是線程安全的，除非他加了鎖（Mutex）或 atomic（原子操作）。而在 string、slice、map 的并發(fā)寫導(dǎo)致出錯(cuò)的場(chǎng)景，更是每隔一段時(shí)間就能在線上看到一兩次。
每次做并發(fā)操作時(shí)，都建議想清楚，這個(gè)場(chǎng)景的到底需不需要保護(hù)共享變量，做好原子操作等。
