大家好，我是煎魚。
在日常工作中，如果我們能夠了解 Go 語言記憶體模型，那會帶來非常大的作用。這樣在看一些極端情況，又或是變態面試題的時候，就能夠明白程式執行表現下的很多根本原因了。
當然，靠一篇普通文章講完 Go 記憶體模型，不可能。因此今天這篇文章，把重點劃在給大家講解 Go 語言的 happens-before 原則這 1 個細節。
開吸，和煎魚揭開他的神祕面紗！
記憶體模型定義是什麼
既然要了解 happens-before 原則，我們得先知道 The Go Memory Model（Go 記憶體模型）定義的是什麼，官方解釋如下：
The Go memory model specifies the conditions under which reads of a variable in one goroutine can be guaranteed to observe values produced by writes to the same variable in a different goroutine.
在 Go 記憶體模型規定：“在一個 goroutine 中讀取一個變數時，可以保證觀察到不同 goroutine 中對同一變數的寫入所產生的值” 的條件。
這是學習後續知識的一個大前提。
happens-before 是什麼
Happens Before 是一個專業術語，與 Go 語言沒有直接關係，也就是並非是特有的。用大白話來講，其定義是：
在一個多執行緒程式中，假設存在 A 和 B 兩個操作，如果 A 操作在 B 操作之前發生（A happens-before B），那麼 A 操作對記憶體的影響將會對執行 B 的執行緒可見。
A 不一定 happens-before B
從 happens-before 定義來看，我們可以反過來想。那就是：
在同一個（相同）執行緒中，如果都執行 A 和 B 操作，並且 A 的宣告一定在 B 之前，那麼 A 一定先於（happens-before）B 發生。
以下述 Go 程式碼例子：
var A int
var B int
func main() {
A = B + 1 (1)
B = 1 (2)
}該程式碼是在同一個 main goroutine，全域性變數 A 在變數 B 之前宣告。
在 main 函式中，程式碼行 (1)，也在程式碼行 (2) 之前。因此我們可以得出 (1) 一定會在 (2) 前執行，對嗎？
答案是：錯誤的，因為 A happens-before B 並不意味著 A 操作一定會在 B 操作之前發生。
實際上在編譯器中，上述程式碼在彙編的真正執行順序如下：
0x0000 00000 (main.go:7) MOVQ "".B(SB), AX
0x0007 00007 (main.go:7) INCQ AX
0x000a 00010 (main.go:7) MOVQ AX, "".A(SB)
0x0011 00017 (main.go:8) MOVQ $1, "".B(SB)- (2)：載入 B 到暫存器 AX。
- (2)：進行 B = 1 賦值，在程式碼中執行為 INCQ 自增。
- (1)：將暫存器 AX 中值加上 1 後賦值給 A。
通過上述分析，我們可以得知。在程式碼行 (1) 在 (2) 之前，但確實 (2) 比 (1) 更早執行。
那麼這是不是意味著違反了 happens-before 的設計原則，畢竟這可是同個執行緒裡的操作，Go 編譯器有 BUG？
其實不然，因為對 A 的賦值實質上對 B 的賦值沒有影響。所以並沒有違反 happens-before 的設計原則。
Go 語言中的 happens-before
在 《The Go Memory Model》 中，給出了 Go 語言中 Happens Before 的明確語言定義。
以下術語將會在介紹中用到：
- 變數 v：一個指代性的變數，用於示例演示。
- 讀 r：代表讀操作。
- 寫 w：代表寫操作。
定義
在滿足如下兩點條件下，允許對變數 v 的讀 r 觀察對 v 的寫 w：
- r 在 w 之前沒有發生。
- 沒有其他寫到 v 的 w' 發生在 w 之後但在 r 之前。
為了保證變數 v 的讀 r 觀察到對 v 的特定寫 w，確保 w 是唯一允許 r 觀察的寫。
因此如果以下兩點都成立，就能保證 r 能觀察到 w ：
- w 發生在 r 之前。
- 對共享變數 v 的任何其他寫入都發生在 w 之前或 r 之後。
這看起來比較生澀，接下來我們以《The Go Memory Model》 中具體的 channel 例子來進行進一步說明，會更好理解一些。
Go Channel 例項
在 Go 語言中提倡不要通過共享記憶體來進行通訊；相反，應當通過通訊來共享記憶體：
Do not communicate by sharing memory; instead, share memory by communicating.
因此在 Go 工程中，Channel 是一個非常常用的語法。在原則上其需要遵守：
- 一個 channel 上的傳送是在該 channel 的相應接收完成之前發生的。
- channel 的關閉發生在接收之前，因為通道被關閉而返回一個零值。
- 一個無緩衝 channel 的接收發生在該 channel 的傳送完成之前。
- 一個容量為 C 的 channel 上，第 k 次接收發生在該 channel 的第 k+C 次傳送完成之前。
接下來根據這四條原則，我們逐一給出例子，用於學習和理解。
例子 1
Go channel 例子 1，你認為輸出的結果是什麼。如下：
var c = make(chan int, 10)
var a string
func f() {
a = "炸煎魚" (1)
c <- 0 (2)
}
func main() {
go f()
<-c (3)
print(a) (4)
}
答案是空字串嗎？
程式最終結果是正常輸出 “炸煎魚” 的，原因如下：
- (1) happens-before (2) 。
- (4) happens-after (3)。
當然，最後 (1) 寫入變數 a 的操作，必然 happens-before 於 (4) print 方法，因此正確的輸出了 “炸煎魚”。
能夠滿足 “一個 channel 上的傳送是在該 channel 的相應接收完成之前發生的”。
例子 2
主要是確保了關閉管道時的行為。只需要在前面的例子中，替換 c <- 0 成 close(c) 就能夠產生具有相同的行為保證的程式。
能夠滿足 “channel 的關閉發生在接收之前，因為通道被關閉而返回一個零值”。
例子 3
Go channel 例子 3，你認為輸出的結果是什麼。如下：
var c = make(chan int)
var a string
func f() {
a = "煎魚進腦子了" (1)
<-c (2)
}
func main() {
go f()
c <- 0 (3)
print(a) (4)
}
答案是空字串嗎？
程式最終結果是正常輸出 “煎魚進腦子了” 的，原因如下：
- (2) happens-before (3)。
- (1) happens-before (4)。
能夠滿足 “一個無緩衝 channel 的接收發生在該 channel 的傳送完成之前”。
如果我們把無緩衝改為 make(chan int, 1)，也就是帶緩衝的 channel，則無法保證正常的輸出 “煎魚進腦子了”。
例子 4
Go channel 例子 4，這個程式為工作列表中的每個條目啟動一個 goroutine，但 goroutine 使用 channel 進行協調，以確保每次最多隻有三個工作函式在執行。
程式碼如下：
var limit = make(chan int, 3)
func main() {
for _, w := range work {
go func(w func()) {
limit <- 1
w()
<-limit
}(w)
}
select{}
}能夠滿足 “一個容量為 C 的 channel 上，第 k 次接收發生在該 channel 的第 k+C 次傳送完成之前”。
總結
在本文中，我們針對 happens-before 原則進行了基本的說明。同時結合 Go 語言中實際的 happens-before 和 happens-after 的場景進了展示和講解。
實際上，在日常的開發工作中，happens-before 原則基本已經深入到潛意識中，就跟設計模式一樣。會不知覺就應用到，但是若我們希望更進一步的對 Go 語言等記憶體模型就行研究和理解，就必須對這個基本理念有所認知。
你平時有沒有注意到這塊的問題呢，歡迎大家留言和討論！
若有任何疑問歡迎評論區反饋和交流，最好的關係是互相成就，各位的點贊就是煎魚創作的最大動力，感謝支援。
文章持續更新，可以微信搜【腦子進煎魚了】閱讀，本文 GitHub github.com/eddycjy/blog 已收錄，學習 Go 語言可以看 Go 學習地圖和路線，歡迎 Star 催更。
參考
- The Go Memory Model
- Go記憶體模型&Happen-Before（一）
- GoLang 記憶體模型
- Golang happens before & channel
- Go 記憶體模型