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 检查出的问题一定要慎重，一个不漏的解决它们；