9.2. sync.Mutex互斥鎖

在8.6節中，我們使用了一個buffered channel作為一個計數信號量，來保證最多隻有20個goroutine會同時執行HTTP請求。同理，我們可以用一個容量只有1的channel來保證最多隻有一個goroutine在同一時刻訪問一個共享變量。一個只能為1和0的信號量叫做二元信號量（binary semaphore）。

gopl.io/ch9/bank2

var (
    sema    = make(chan struct{}, 1) // a binary semaphore guarding balance
    balance int
)

func Deposit(amount int) {
    sema <- struct{}{} // acquire token
    balance = balance + amount
    <-sema // release token
}

func Balance() int {
    sema <- struct{}{} // acquire token
    b := balance
    <-sema // release token
    return b
}

這種互斥很實用，而且被sync包裡的Mutex類型直接支持。它的Lock方法能夠獲取到token(這裡叫鎖)，並且Unlock方法會釋放這個token：

gopl.io/ch9/bank3

import "sync"

var (
    mu      sync.Mutex // guards balance
    balance int
)

func Deposit(amount int) {
    mu.Lock()
    balance = balance + amount
    mu.Unlock()
}

func Balance() int {
    mu.Lock()
    b := balance
    mu.Unlock()
    return b
}

每次一個goroutine訪問bank變量時（這裡只有balance餘額變量），它都會調用mutex的Lock方法來獲取一個互斥鎖。如果其它的goroutine已經獲得了這個鎖的話，這個操作會被阻塞直到其它goroutine調用了Unlock使該鎖變回可用狀態。mutex會保護共享變量。慣例來說，被mutex所保護的變量是在mutex變量聲明之後立刻聲明的。如果你的做法和慣例不符，確保在文檔裡對你的做法進行說明。

在Lock和Unlock之間的代碼段中的內容goroutine可以隨便讀取或者修改，這個代碼段叫做臨界區。鎖的持有者在其他goroutine獲取該鎖之前需要調用Unlock。goroutine在結束後釋放鎖是必要的，無論以哪條路徑通過函數都需要釋放，即使是在錯誤路徑中，也要記得釋放。

上面的bank程序例證了一種通用的併發模式。一系列的導出函數封裝了一個或多個變量，那麼訪問這些變量唯一的方式就是通過這些函數來做（或者方法，對於一個對象的變量來說）。每一個函數在一開始就獲取互斥鎖並在最後釋放鎖，從而保證共享變量不會被併發訪問。這種函數、互斥鎖和變量的編排叫作監控monitor（這種老式單詞的monitor是受“monitor goroutine”的術語啟發而來的。兩種用法都是一個代理人保證變量被順序訪問）。

由於在存款和查詢餘額函數中的臨界區代碼這麼短——只有一行，沒有分支調用——在代碼最後去調用Unlock就顯得更為直截了當。在更復雜的臨界區的應用中，尤其是必須要儘早處理錯誤並返回的情況下，就很難去（靠人）判斷對Lock和Unlock的調用是在所有路徑中都能夠嚴格配對的了。Go語言裡的defer簡直就是這種情況下的救星：我們用defer來調用Unlock，臨界區會隱式地延伸到函數作用域的最後，這樣我們就從“總要記得在函數返回之後或者發生錯誤返回時要記得調用一次Unlock”這種狀態中獲得瞭解放。Go會自動幫我們完成這些事情。

func Balance() int {
    mu.Lock()
    defer mu.Unlock()
    return balance
}

上面的例子裡Unlock會在return語句讀取完balance的值之後執行，所以Balance函數是併發安全的。這帶來的另一點好處是，我們再也不需要一個本地變量b了。

此外，一個deferred Unlock即使在臨界區發生panic時依然會執行，這對於用recover（§5.10）來恢復的程序來說是很重要的。defer調用只會比顯式地調用Unlock成本高那麼一點點，不過卻在很大程度上保證了代碼的整潔性。大多數情況下對於併發程序來說，代碼的整潔性比過度的優化更重要。如果可能的話儘量使用defer來將臨界區擴展到函數的結束。

考慮一下下面的Withdraw函數。成功的時候，它會正確地減掉餘額並返回true。但如果銀行記錄資金對交易來說不足，那麼取款就會恢復餘額，並返回false。

// NOTE: not atomic!
func Withdraw(amount int) bool {
    Deposit(-amount)
    if Balance() < 0 {
        Deposit(amount)
        return false // insufficient funds
    }
    return true
}

函數終於給出了正確的結果，但是還有一點討厭的副作用。當過多的取款操作同時執行時，balance可能會瞬時被減到0以下。這可能會引起一個併發的取款被不合邏輯地拒絕。所以如果Bob嘗試買一輛sports car時，Alice可能就沒辦法為她的早咖啡付款了。這裡的問題是取款不是一個原子操作：它包含了三個步驟，每一步都需要去獲取並釋放互斥鎖，但任何一次鎖都不會鎖上整個取款流程。

理想情況下，取款應該只在整個操作中獲得一次互斥鎖。下面這樣的嘗試是錯誤的：

// NOTE: incorrect!
func Withdraw(amount int) bool {
    mu.Lock()
    defer mu.Unlock()
    Deposit(-amount)
    if Balance() < 0 {
        Deposit(amount)
        return false // insufficient funds
    }
    return true
}

上面這個例子中，Deposit會調用mu.Lock()第二次去獲取互斥鎖，但因為mutex已經鎖上了，而無法被重入（譯註：go裡沒有重入鎖，關於重入鎖的概念，請參考java）——也就是說沒法對一個已經鎖上的mutex來再次上鎖——這會導致程序死鎖，沒法繼續執行下去，Withdraw會永遠阻塞下去。

關於Go的mutex不能重入這一點我們有很充分的理由。mutex的目的是確保共享變量在程序執行時的關鍵點上能夠保證不變性。不變性的一層含義是“沒有goroutine訪問共享變量”，但實際上這裡對於mutex保護的變量來說，不變性還包含更深層含義：當一個goroutine獲得了一個互斥鎖時，它能斷定被互斥鎖保護的變量正處於不變狀態（譯註：即沒有其他代碼塊正在讀寫共享變量），在其獲取並保持鎖期間，可能會去更新共享變量，這樣不變性只是短暫地被破壞，然而當其釋放鎖之後，鎖必須保證共享變量重獲不變性並且多個goroutine按順序訪問共享變量。儘管一個可以重入的mutex也可以保證沒有其它的goroutine在訪問共享變量，但它不具備不變性更深層含義。（譯註：更詳細的解釋，Russ Cox認為可重入鎖是bug的溫床，是一個失敗的設計）

一個通用的解決方案是將一個函數分離為多個函數，比如我們把Deposit分離成兩個：一個不導出的函數deposit，這個函數假設鎖總是會被保持並去做實際的操作，另一個是導出的函數Deposit，這個函數會調用deposit，但在調用前會先去獲取鎖。同理我們可以將Withdraw也表示成這種形式：

func Withdraw(amount int) bool {
    mu.Lock()
    defer mu.Unlock()
    deposit(-amount)
    if balance < 0 {
        deposit(amount)
        return false // insufficient funds
    }
    return true
}

func Deposit(amount int) {
    mu.Lock()
    defer mu.Unlock()
    deposit(amount)
}

func Balance() int {
    mu.Lock()
    defer mu.Unlock()
    return balance
}

// This function requires that the lock be held.
func deposit(amount int) { balance += amount }

當然，這裡的存款deposit函數很小，實際上取款Withdraw函數不需要理會對它的調用，儘管如此，這裡的表達還是表明了規則。

封裝（§6.6），用限制一個程序中的意外交互的方式，可以使我們獲得數據結構的不變性。因為某種原因，封裝還幫我們獲得了併發的不變性。當你使用mutex時，確保mutex和其保護的變量沒有被導出（在go裡也就是小寫，且不要被大寫字母開頭的函數訪問啦），無論這些變量是包級的變量還是一個struct的字段。