The Go Memory Model / Happens Before 是什么？

作者：Pipeliu 2025-06-04 04:10:00

“Happens Before”是 Go 內存模型中用以描述不同 goroutine 中操作之間可見性順序的核心概念。簡單來說，如果事件 A “happens before” 事件 B，那么事件 A 的結果保證對事件 B 可見。這種關系是傳遞的：如果 A happens before B，且 B happens before C，那么 A happens before C。

Happens Before (先行發生)

“Happens Before”關系主要由以下兩種情況構成：

Sequenced Before (順序先于)

定義：在單個 goroutine 內部，操作的執行順序遵循代碼中語句的順序。例如，在 x = 1; y = x + 1 中，對 x 的賦值操作順序先于對 y 的賦值操作。
作用：這是最直觀的排序，保證了單個 goroutine 內代碼的邏輯按預期執行。

Synchronized Before (同步先于)

定義：當不同的 goroutine 通過同步原語（如通道操作、互斥鎖等）進行交互時，這些原語會建立起 goroutine 間的同步關系。例如，對一個通道的發送操作，如果成功匹配到接收操作，那么發送完成“同步先于”接收完成。
作用：這是跨 goroutine 保證內存可見性的關鍵。同步操作不僅協調執行，還確保一個 goroutine 中的寫操作對另一個 goroutine 中的后續讀操作可見。

Happens Before = Sequenced Before ∪ Synchronized Before (取傳遞閉包)

最終的“Happens Before”關系是“順序先于”和“同步先于”關系的并集的傳遞閉包。這意味著，一系列操作，即使跨越多個 goroutine，只要它們能通過“順序先于”和“同步先于”鏈接起來，就能形成一個“Happens Before”鏈條。

為什么重要？

對于一個普通的（非同步的）內存讀取操作 r，如果要保證它能觀察到某個寫入操作 w 的值，必須滿足：

w happens before r.
沒有其他的寫入操作 w' (針對同一內存位置) 滿足 w happens before w' 且 w' happens before r。

如果一個程序沒有數據競爭（Data Race-Free, DRF），即所有對共享變量的并發訪問都通過同步原語進行了保護，那么該程序的執行就如同所有 goroutine 的操作被以某種順序交錯在一個單一處理器上執行一樣，這被稱為“順序一致性”（Sequentially Consistent, DRF-SC）。

通道通信的同步細節 (Channel Communication Synchronization Details)

通道是 Go 中主要的 goroutine 間同步機制。每一次在特定通道上的發送操作都會與該通道上相應的接收操作相匹配。

以下是文檔中提到的關于通道通信建立的“Synchronized Before”關系的具體規則：

“A send on a channel is synchronized before the completion of the corresponding receive from that channel.”

中文：對一個通道的發送操作，同步先于 (happens before) 從該通道完成的相應接收操作。
解釋：這條規則是最基礎的。無論通道是帶緩沖的還是不帶緩沖的，一旦一個值被成功發送，并且這個值被接收方成功接收，那么發送這個動作（及其之前的所有在同一 goroutine 中的操作）對于接收完成這個動作（及其之后的所有在同一 goroutine 中的操作）是可見的。
例子

var c = make(chan int, 10) // 可以是帶緩沖或不帶緩沖
var a string

func f() {
    a = "hello, world" // (1) 對 a 的寫操作
    c <- 0             // (2) 對 c 的發送操作
}

func main() {
    go f()
    <-c                // (3) 從 c 的接收操作
    print(a)           // (4) 對 a 的讀操作
}

在這個例子中：

(1) 順序先于 (2) (在 goroutine f 內部)。
根據本條規則，(2) (發送) 同步先于 (3) (接收完成)。
(3) 順序先于 (4) (在 goroutine main 內部)。
因此，通過傳遞性，對 a 的寫操作 (1) happens before 對 a 的讀操作 (4)。所以程序保證打印出 "hello, world"。

“The closing of a channel is synchronized before a receive that returns a zero value because the channel is closed.”

中文：關閉一個通道的操作，同步先于 (happens before) 因通道已關閉而返回零值的接收操作。
解釋：當一個通道被關閉后，任何后續的接收操作會立即返回一個該通道類型的零值，并且第二個返回值 (通常是 ok) 會是 false。這個規則保證，關閉通道的動作（及其之前的所有操作）對于那個感知到通道已關閉的接收操作是可見的。
例子：如果將上一個例子中的 c <- 0 替換為 close(c)，行為保證是相同的。main 中的 <-c 會因為通道關閉而返回 (對于 int 類型是 0)，print(a) 仍然會打印 "hello, world"。

“A receive from an unbuffered channel is synchronized before the completion of the corresponding send on that channel.”

中文：從一個無緩沖通道的接收操作，同步先于 (happens before) 在該通道上完成的相應發送操作。
解釋：這條規則特定于無緩沖通道。無緩沖通道的發送和接收是同步的，發送方會阻塞直到接收方準備好接收，接收方也會阻塞直到發送方準備好發送。這條規則意味著，接收方goroutine中，接收操作完成前的所有操作，對于發送方goroutine中，發送操作完成后的所有操作，是可見的。這與第一條規則方向相反，共同確立了無緩沖通道的“會合點”(rendezvous)特性。
例子

var c = make(chan int) // 無緩沖通道
var a string

func f() {
    a = "hello, world" // (1) 對 a 的寫操作
    <-c                // (2) 從 c 的接收操作
}

func main() {
    go f()
    c <- 0             // (3) 對 c 的發送操作
    print(a)           // (4) 對 a 的讀操作
}

在這個例子中：

(1) 順序先于 (2) (在 goroutine f 內部)。
根據本條規則，(2) (接收) 同步先于 (3) (發送完成)。
(3) 順序先于 (4) (在 goroutine main 內部)。
因此，對 a 的寫操作 (1) happens before 對 a 的讀操作 (4)。程序同樣保證打印 "hello, world"。
注意：如果 c 是一個帶緩沖通道 (例如 make(chan int, 1))，這個程序就不能保證打印 "hello, world"。因為發送操作 (3) 可能在 f 中的接收操作 (2) 執行之前就完成了（如果緩沖區未滿），這樣就不會建立 (2) 同步先于 (3) 的關系。

“The k-th receive on a channel with capacity C is synchronized before the completion of the k+C-th send from that channel completes.”

中文：對于一個容量為 C 的通道，第 k 個接收操作，同步先于 (happens before) 該通道上的第 k+C 個發送操作的完成。
解釋：這條規則是針對帶緩沖通道的，它推廣了無緩沖通道的規則，并允許使用帶緩沖通道來建模計數信號量。可以這樣理解：當通道滿了（即已經有 C 個元素在緩沖中，等待被接收），下一個（即第 C+1 個）發送操作必須等待通道中至少有一個元素被接收出去后才能完成。更一般地，第 k+C 個發送者必須等待第 k 個接收者完成后才能繼續。
作用：這允許我們限制并發數量。通道中的元素數量代表活躍的“許可”，通道的容量代表最大并發數。發送操作獲取許可，接收操作釋放許可。
例子

var limit = make(chan int, 3) // 容量 C = 3

func main() {
    // 假設 work 是一個包含多個待執行任務的切片
    for _, w := range work {
        go func(job func()) {
            limit <- 1   // (發送) 獲取一個許可。如果 limit 已滿 (3個goroutine已獲取)，這里會阻塞
            job()        // 執行任務
            <-limit      // (接收) 釋放一個許可
        }(w)
    }
    select{} // 保持 main goroutine 存活
}

在這個例子中，limit 通道確保最多只有3個 job 同時運行。

當第1, 2, 3個 goroutine 執行 limit <- 1 (發送) 時，它們都能成功并將元素放入通道。
當第4個 goroutine 嘗試執行 limit <- 1 (第4次發送) 時，由于通道已滿 (3個元素)，它會阻塞。
這符合規則：第1個接收 (k=1) 必須發生在第 1+3=4 個發送完成之前。也就是說，只有當最早獲取許可的3個 goroutine 中的某一個完成了它的 job() 并執行了 <-limit (第1次接收)，釋放了一個位置后，第4個 goroutine 的 limit <- 1 (第4次發送) 才能成功。

總結一下，通道的這些同步規則是 Go 并發編程中正確性的基石。通過理解并正確使用這些規則，開發者可以構建出沒有數據競爭且行為可預測的并發程序。這些規則定義了明確的“Happens Before”邊界，從而保證了內存操作的可見性。

數據競爭的處理方式

精華：Go明確定義了數據競爭（data race），即多個goroutine同時訪問同一內存位置且至少有一個是寫操作，且沒有同步保護。不同于C/C++的未定義行為，Go在檢測到數據競爭時可能會報告并終止程序，或者允許讀取并發寫入的值，但結果是有限的。
為什么不容易注意到：您可能習慣于通過go build -race檢測數據競爭，但對Go在數據競爭下的具體行為（例如不會像C/C++那樣徹底不可預測）缺乏深入思考。
值得學習：理解Go對數據競爭的處理方式，可以幫助您更好地調試程序，避免依賴未定義行為的假設。此外，這也強化了Go鼓勵使用同步機制的哲學，對比C/C++的差異能讓您更欣賞Go的設計。

不正確同步的示例與陷阱

精華：文檔列舉了幾個常見的錯誤同步模式，例如

var a string
var done bool

func setup() {
    a = "hello, world"
    done = true
}

func doprint() {
    if !done {
        once.Do(setup)
    }
    print(a)
}

func twoprint() {
    go doprint()
    go doprint()
}

雙重檢查鎖定（Double-Checked Locking）：but there is no guarantee that, in doprint, observing the write to done implies observing the write to a. This version can (incorrectly) print an empty string instead of "hello, world".

var a string
var done bool

func setup() {
    a = "hello, world"
    done = true
}

func main() {
    go setup()
    for !done {
    }
    print(a)
}

忙等待（Busy Waiting）：As before, there is no guarantee that, in main, observing the write to done implies observing the write to a, so this program could print an empty string too. Worse, there is no guarantee that the write to done will ever be observed by main, since there are no synchronization events between the two threads. The loop in main is not guaranteed to finish.

為什么不容易注意到：這些錯誤模式在單線程邏輯中看似合理，但在并發環境下會失效。有經驗的開發者可能偶爾依賴這些“巧妙”的方法，而未意識到它們的風險。
值得學習：通過研究這些反例，您可以避免在代碼中犯類似錯誤。例如，解決這些問題的正確方法是顯式同步（如使用鎖或通道），這能顯著提高代碼的健壯性。

編譯器優化的限制

精華：Go內存模型對編譯器優化施加了嚴格限制，以確保并發程序的正確性。例如

編譯器不能將寫操作移出條件語句

不能假設循環會終止或函數會返回，以避免引入意外的內存訪問

單次讀操作不能觀察到多個值，單次寫操作不能寫入多個值

為什么不容易注意到：這些限制主要影響底層編譯器行為，作為應用開發者，您可能很少直接接觸。但它們間接決定了您的代碼在并發環境下的表現。
值得學習：理解這些限制能幫助您在編寫高性能代碼時，預判哪些優化是安全的。例如，知道編譯器不會重新加載共享變量，可以避免在復雜邏輯中意外丟失同步保護。

通道通信的同步細節

精華：文檔詳細描述了通道的同步行為：

無緩沖通道的接收在發送完成之前“happens before”發送完成。

緩沖通道的第 k 次接收在第 k+C 次發送完成之前“happens before”發送完成（C為通道容量）。

關閉通道在接收到零值之前“happens before”。

為什么不容易注意到：您可能已經熟練使用通道，但對緩沖與無緩沖通道的同步差異、以及關閉通道的精確行為關注不夠。
值得學習：掌握這些細節能幫助您在設計并發模式時（如信號量、限流）更精準地控制goroutine間的同步。例如，理解緩沖通道的同步規則，可以避免因容量誤判導致的死鎖或數據丟失。

原子操作的同步能力

精華：sync/atomic包中的原子操作（如AddInt32、CompareAndSwap）不僅提供無鎖操作，還能建立goroutine間的同步關系。所有原子操作表現得像在一個順序一致的順序中執行。
為什么不容易注意到：原子操作常被視為性能優化工具，而其同步能力可能被忽視。
值得學習：在需要輕量級同步的場景下，正確使用原子操作可以替代鎖，減少開銷。例如，理解原子操作的“happens before”關系，可以在高并發計數器或狀態標志中確保一致性。

Finalizers的同步行為

精華：runtime.SetFinalizer(x, f)在finalizer f(x)調用之前“happens before”，這是垃圾回收前清理資源的高級機制。
為什么不容易注意到：finalizers是Go中的高級特性，日常開發中用得不多，且其同步細節容易被忽略。
值得學習：如果您需要在并發環境中管理資源（如文件句柄、網絡連接），理解finalizers的同步行為能幫助您正確實現清理邏輯，避免資源泄露或競爭問題。

責任編輯：武曉燕來源： Piper蛋窩

Happens Go 內存