Go Mutex 复制后为什么解锁异常

如果一个结构体里嵌着 sync.Mutex，复制结构体就不只是复制几个普通字段。锁的内部状态、等待关系和被保护的数据会被拆成两份，调用者以为仍在操作同一把锁，实际上已经出现了两个互不认识的锁。因此，Go 官方明确要求：Mutex 首次使用后不能再复制。

解锁异常的根因通常不是 Unlock 写错，而是含锁对象在使用后被按值复制；修复重点是让对象和方法都保持指针语义，并用 go vet -copylocks 找出隐式复制。

为什么复制后会出现“解锁异常”

sync.Mutex 的零值是未加锁状态，适合直接作为结构体字段使用。但 Lock 之后，内部状态已经代表一把正在协调 goroutine 的锁。此时执行 b := a，只是把字段位面复制到新对象，等待者、竞争关系和原对象的身份并没有被重新建立。

如果原对象已经处于 locked 状态，新副本可能也带着“已锁定”的标记，却没有原锁的等待队列。对副本调用 Unlock 可能让副本看似恢复，对原对象却没有任何帮助；如果复制发生在某个分支、回调或延迟解锁之间，还可能触发 sync: unlock of unlocked mutex，或者更隐蔽地让两份数据同时进入临界区。这个问题的危险处在于，它不一定每次都立刻 panic。

四个最容易漏掉的复制入口

最典型的错误是给含锁结构体写值接收者。编译器会先复制接收者，再在副本上取锁，所以每次调用都可能锁住不同的 Mutex：

package counter

import "sync"

type Counter struct {
	mu sync.Mutex
	n  int
}

// 错误示例：值接收者会复制 Counter，锁住的是临时副本。
func (c Counter) Inc() {
	c.mu.Lock()
	defer c.mu.Unlock() // 只解锁副本，无法保护调用者的 c.n
	c.n++
}

// 正确示例：指针接收者始终访问同一个 Mutex 和同一份数据。
func (c *Counter) Add(delta int) {
	c.mu.Lock()
	defer c.mu.Unlock() // 保证异常返回时也释放同一把锁
	c.n += delta
}

另外三类入口也要一起搜：把 Counter 作为函数参数或返回值、执行 other := original，以及对 []Counter 使用 append 或 for _, item := range items。map 取值也会得到结构体副本。只把方法改成指针接收者还不够，调用链中仍然按值传递时，问题会在更早的位置发生。

把含锁对象改回稳定的指针语义

业务对象通常应由指针创建和传递，让拷贝动作变成复制指针而不是复制结构体。构造函数不是为了给 Mutex 做特殊初始化，而是把正确的生命周期和调用方式固定下来：

package counter

import "sync"

type Counter struct {
	mu sync.Mutex
	n  int
}

// NewCounter 返回指针，调用方不会无意中复制含锁结构体。
func NewCounter() *Counter {
	return &Counter{}
}

// Value 在同一把锁下读取数据，避免读写交叉。
func (c *Counter) Value() int {
	c.mu.Lock()
	defer c.mu.Unlock() // 读取结束后释放当前对象的锁
	return c.n
}

// Add 在同一把锁下修改数据，参数只复制普通整数。
func (c *Counter) Add(delta int) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.n += delta
}

如果结构体必须放进集合，优先使用 []*Counter；如果必须通过接口传递，也让接口里存放指针。不要用反射、序列化或“复制后清空 Mutex”来规避警告，因为那会把锁和数据的一致性责任推给调用方。

用 go vet 和 race detector 做最后确认

copylocks 分析器会检查锁被错误地按值传递，发现问题后应修代码，而不是简单关闭检查：

# 静态检查所有包，重点查看 copylocks 报告的调用位置
go vet -copylocks ./...

# 在已有并发测试上检查运行期数据竞争；覆盖不到的路径不会被发现
go test -race ./...

两者职责不同：go vet 能在没有跑到异常分支时提示“复制了锁”，-race 则观察真实执行中的共享数据访问。前者通过后，还要确认测试和生产入口没有把对象重新装回值类型；后者报错时优先回到对象所有权和锁边界，而不是盲目增加另一把 Mutex。

常见问题

Mutex 在第一次使用前可以复制吗？

零值、尚未使用的 Mutex 通常可以复制，但工程上很难长期证明这一点。只要对象可能被并发调用，就应从创建开始保持指针语义。

为什么 go vet 报警但程序暂时没崩？

copylocks 是静态风险提示，不代表每次复制都会立即 panic。副本可能暂时各自工作，却已经失去对同一份数据的共同保护。

加一把新锁能修复复制问题吗？

不能。新锁只能保护新的边界，无法恢复原对象与副本之间的同步关系。先消除含锁结构体的按值复制，再决定是否需要调整锁粒度。