就是不让你拷贝的意思。

不是所有的东西都可以拷贝的，比如sync包下面的Mutex结构体，就是不可以拷贝的。为了防止有些不应该被拷贝的对象被拷贝，于是就有了noCopy。

golang中如何禁止复制

noCopy是一个golang基础包内部的结构体（小写开头，说明不对外暴露，不想让用户调用），其声明如下：

type noCopy struct{}

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

当我们声明的结构体里包含noCopy时：

type DoNotCopyMe struct {
  noCopy
}

var d DoNotCopyMe
d2 := d // 这里发生了拷贝

编译器是不会报错的，对，你没有看错，编译器是不会报错的，只能用vet工具检查:

// 假设我们上面的代码写在main.go文件中
go vet main.go
// 会看到如下输出
./main.go:616:11: assignment copies lock value to d2: command-line-arguments.DoNotCopyMe contains command-line-arguments.noCopy
./main.go:618:23: call of fmt.Printf copies lock value: command-line-arguments.DoNotCopyMe contains command-line-arguments.noCopy

如果没有错误的使用不能被copy的代码审核，运行命令时不会看到输出。

从上面的实验我们可以得出两点结论：

1. 如果一个结构体实现了Lock和Unlock函数，原则上就不能被拷贝。

2. 但是编译器没有做限制，如果想知道代码里是否有错误的用法，需要用go vet命令检查。

为什么sync.Mutex不能复制

如果说实现了Lock和Unlock方法的结构体是不能复制的，那么sync包下的Mutex肯定是符合条件的，是不允许被复制的，我们来看个例子。

type Container struct {
  sync.Mutex                       
  counters map[string]int
}

func (c Container) inc(name string) {
  c.Lock()                         
  defer c.Unlock()
  c.counters[name]++
}

func main() {
  c := Container{counters: map[string]int{"a": 0, "b": 0}}

  doIncrement := func(name string, n int) {
    for i := 0; i < n; i++ {
      c.inc(name) // A
    }
  }

  go doIncrement("a", 100000)
  go doIncrement("a", 100000)

  time.Sleep(300 * time.Millisecond)
  fmt.Println(c.counters)
}

让我们运行一下，看会发生什么？

fatal error: concurrent map writes

抛异常了。

按说这段代码是可以正常工作的呀，我们考虑到了map是不支持并发的，所以使用了互斥锁来保护map，为什还会发生异常呢？

问题出在A部分，这里发生了对象拷贝，也就是说，一个规定了noCopy的对象被拷贝了。

我们如果修改上面的代码，使它能正常工作呢？

我们在声明inc方法的时候，应该这样声明：

func (c *Container) inc(name string) {
  c.Lock()                         
  defer c.Unlock()
  c.counters[name]++
}

把c改成指针类型就可以了，当c无论在哪里引用，都是同一个c，那么内部使用的还是同一个Mutex对象，是不会发生拷贝的。

Mutex会产生异常更本质的原因

以后我们再写文章去解析Mutex的原理，今天我们只对Mutex做浅显的研究，能解决我们的疑惑即可。我们看下Mutex的结构体，在mutext.go文件里，它是这样定义的：

// A Mutex must not be copied after first use.
type Mutex struct {
  state int32
  sema  uint32
}

在这个结构体里并没有指针，也就是说，外面c变量被拷贝了多少次，Mutex也被拷贝了多少次，这里没有任何东西是共享的，每个goroutine里使用的Mutex实例都是自己的，并不是公用的，但是因为map的本质是一个指针，所以map倒是公用的。这就相当于每个人都有自己的钥匙，却要去开同一把锁，产生竞争是必然的，map中有并发检查，于是就抛异常了。

所以，在了解到问题的本质后，我们还有另一种解法：

type Container struct {
    *sync.Mutex
    counters map[string]int
}

c := Container{counters: map[string]int{"a": 0, "b": 0}, Mutex: &sync.Mutex{}}

把sync.Mutex定义成一个指针，这样外面的c变量无论被拷贝多少次，内部使用的锁还是同一个，也能保持并发的inc方法能正常执行。

在结构体中引用了Mutex后，很容易在拷贝后发生并发错误。所以总是把Mutex声明为指针不失为一个安全的方法。

type AlwaysSafe struct {
  mux *sync.Mutex 
}

只是要记得初始化：

a := AlwaysSafe{mux: &sync.Mutex{}}

参考

链接