9.4. 內存同步

你可能比較糾結為什麼Balance方法需要用到互斥條件，無論是基於channel還是基於互斥量。畢竟和存款不一樣，它只由一個簡單的操作組成，所以不會碰到其它goroutine在其執行“期間”執行其它邏輯的風險。這裡使用mutex有兩方面考慮。第一Balance不會在其它操作比如Withdraw“中間”執行。第二（更重要的）是“同步”不僅僅是一堆goroutine執行順序的問題，同樣也會涉及到內存的問題。

在現代計算機中可能會有一堆處理器，每一個都會有其本地緩存（local cache）。為了效率，對內存的寫入一般會在每一個處理器中緩衝，並在必要時一起flush到主存。這種情況下這些數據可能會以與當初goroutine寫入順序不同的順序被提交到主存。像channel通信或者互斥量操作這樣的原語會使處理器將其聚集的寫入flush並commit，這樣goroutine在某個時間點上的執行結果才能被其它處理器上運行的goroutine得到。

考慮一下下面代碼片段的可能輸出：

var x, y int
go func() {
    x = 1 // A1
    fmt.Print("y:", y, " ") // A2
}()
go func() {
    y = 1                   // B1
    fmt.Print("x:", x, " ") // B2
}()

因為兩個goroutine是併發執行，並且訪問共享變量時也沒有互斥，會有數據競爭，所以程序的運行結果沒法預測的話也請不要驚訝。我們可能希望它能夠打印出下面這四種結果中的一種，相當於幾種不同的交錯執行時的情況：

y:0 x:1
x:0 y:1
x:1 y:1
y:1 x:1

第四行可以被解釋為執行順序A1,B1,A2,B2或者B1,A1,A2,B2的執行結果。然而實際運行時還是有些情況讓我們有點驚訝：

x:0 y:0
y:0 x:0

根據所使用的編譯器，CPU，或者其它很多影響因子，這兩種情況也是有可能發生的。那麼這兩種情況要怎麼解釋呢？

在一個獨立的goroutine中，每一個語句的執行順序是可以被保證的，也就是說goroutine內順序是連貫的。但是在不使用channel且不使用mutex這樣的顯式同步操作時，我們就沒法保證事件在不同的goroutine中看到的執行順序是一致的了。儘管goroutine A中一定需要觀察到x=1執行成功之後才會去讀取y，但它沒法確保自己觀察得到goroutine B中對y的寫入，所以A還可能會打印出y的一箇舊版的值。

儘管去理解併發的一種嘗試是去將其運行理解為不同goroutine語句的交錯執行，但看看上面的例子，這已經不是現代的編譯器和cpu的工作方式了。因為賦值和打印指向不同的變量，編譯器可能會斷定兩條語句的順序不會影響執行結果，並且會交換兩個語句的執行順序。如果兩個goroutine在不同的CPU上執行，每一個核心有自己的緩存，這樣一個goroutine的寫入對於其它goroutine的Print，在主存同步之前就是不可見的了。

所有併發的問題都可以用一致的、簡單的既定的模式來規避。所以可能的話，將變量限定在goroutine內部；如果是多個goroutine都需要訪問的變量，使用互斥條件來訪問。