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