Go 的 noCopy 是什麼機制？

你是否遇到過 assignment copies lock 的錯誤？

當我們用 go vet 檢查靜態問題的時候，你是否遇到 noCopy 相關的錯誤。最典型的就是 lock 的變量，測試代碼：

func main() {
    var mu sync.Mutex
    var i int
    // mu 重新拷貝出來一個
    m := mu 
    m.Lock()
    i += 1
    m.Unlock()
}

靜態檢查的時候報錯：

➜  locktest git:(master) ✗ go vet ./...
# example/locktest
./test_lock.go:9:7: assignment copies lock value to m: sync.Mutex

遇到這種語法提示可不能大意，一定要解決。以免給以後埋坑。那童鞋是否想過，爲什麼鎖不能拷貝？

爲什麼鎖不能拷貝？

很多時候我們被直接告訴了答案，Mutex 鎖不能拷貝。但是原因呢？

劃重點：變量資源本身帶狀態且操作要配套的不能拷貝。

比如說 Mutex 鎖，WaitGroup ，這些本身都是帶狀態的信息的。並且它們操作一定要配套，不然就會死鎖。什麼意思？

鎖的配套：

mu.Lock()
mu.Unlock()

WaitGroup 的配套：

wg.Add(1)
wg.Done()

這種一定要嚴格的匹配，一次加鎖對應一次解鎖，數量不對就會出問題。

回到問題本身，爲什麼鎖不能拷貝？

因爲拷貝了很容易會導致操作次數不匹配。很容易理解，拷貝就是創建了一個新的變量，舊的變量加了鎖，新的變量解鎖。牛頭不對馬嘴，豈不就死鎖了。就算不死鎖也可能達不到鎖互斥的目的。看個簡單的例子：

func main() {
    var mu sync.Mutex
    var i int

    // 第一次加鎖放鎖
    mu.Lock()
    //...
    // 不知道爲啥拷出來
    m := mu
    i += 1
    m.Unlock()

    // 第二次加鎖放鎖 
    mu.Lock()
    i += 1
    mu.Unlock()
}

上面就死鎖了。有童鞋可能會反駁，我怎麼可能犯這種低級錯誤。那再來一個：

type Obj struct {
    mu sync.Mutex
    // ... 其他字段
}

func (o Obj) Lock()        { o.mu.Lock() }
func (o Obj) Dosomething() {}
func (o Obj) Unlock()      { o.mu.Unlock() }

func main() {
    o := Obj{}

    o.Lock()
    o.Dosomething()
    o.Unlock()

    o.Lock()
    o.Dosomething()
    o.Unlock()
}

這種運行起來也是報錯的，因爲鎖變量的拷貝導致加鎖解鎖不是配套的操作。

再舉個例子，看一個 WaitGroup 很典型的死鎖問題：

func doSomething(wg sync.WaitGroup) {
    defer wg.Done()
    // ...
}
func main() {
    var wg sync.WaitGroup
    wg.Add(1)
    doSomething(wg)
    wg.Wait()
}

上面的 wg 使用也會導致死鎖。歸根結底就是 WaitGroup 的變量操作沒配套。

劃重點：針對需要配套操作的變量類型，基本上都會要求 noCopy 的，否則拷貝出來就亂套了。

在上萬行的業務代碼場景，可能你的問題更隱蔽。很悲傷的是，上面的三個例子都能正常編譯。好消息是，上面三個例子都能用 go vet 檢查出來。所以大家一定要善用 go vet 來配合檢查，能夠過濾大部分的低級問題。

noCopy 機制

Go 沒有更好的辦法阻止拷貝對象，於是通過了一個 noCopy 的機制。這個不能阻止編譯，但是可以讓 go vet 能再靜態檢查的時候檢查出來。Go 裏面通過實現一個 noCopy 的結構體，然後嵌入這個結構體就能讓 go vet 檢查出來。

type noCopy struct{}
// Lock is a no-op used by -copylocks checker from `go vet`.
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}

類似於 Mutex，WaitGroup ，變量嵌入了這個 noCopy 的類型，就能被 go vet 檢查出來。

通常業務如果也有不讓拷貝的需求，會怎麼做呢？

最簡單的是：嵌入 sync.Mutex 變量。就能讓這個變量也具有 noCopy 的功能。

哪些類型不能拷貝？

比如 Mutex Lock，Cond，Pool，WaitGroup 。這些資源都嚴格要求操作要配套：

// Mutex
Lock()
Unlock()

// WaitGroup
Add()
Done()

// Pool
Put()
Get()

// Cond 一定要配合 Lock 
c.L.Lock()
for !condition() {
   c.Wait()
}
// ... make use of condition ...
c.L.Unlock()

不配套的操作，就會出問題。

總結

  1. 類似於 Mutex Lock，WaitGroup 等資源一定要操作配套，加鎖一定對應解鎖。否則牛頭不對馬嘴就一定會出問題；

  2. “拷貝” 就是出現這種不一致的源頭之一。所以 noCopy 就是解決這個問題的方案；

  3. Go 沒有更好的辦法阻止你 Copy，沒法在編譯的時候阻止。但提供了 noCopy 機制，讓程序員可以在 go vet 檢查出來；

  4. go vet 檢查出的問題一定要慎重，一個不漏的解決它們；

堅持思考，方向比努力更重要。關注我：奇伢雲存儲。歡迎加我好友，技術交流。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/B8WYSCkjoOoZP7a575yX7A

猜你喜歡