互斥锁复制

“互斥锁复制”最容易出现在看起来很普通的 Go 代码里：给带有 sync.Mutex 的结构体写了一个值接收者方法，或者为了返回结果把结构体直接赋值。编译器不会把这种复制当成语法错误，但锁的内部状态已经被复制，原对象与副本不再是同一个保护单元。

只要 sync.Mutex 已经使用过，就不要再复制包含它的值。共享对象用指针传递，修改方法用指针接收者；再用 go vet 的 copylocks 检查按值传递。

为什么复制后锁和数据不再是同一个保护单元

官方 sync 文档把“不要复制”写在包级说明中；Mutex 的约束更具体：零值可直接使用，但第一次使用后不能复制。原因不是“复制一个整数”这么简单，而是锁代表了一组等待者、持有状态和同步关系。把结构体复制后，副本拥有另一份锁状态，却不一定拥有一份独立且自洽的数据协议。

下面这个值接收者就是典型陷阱：

type Counter struct {
    mu sync.Mutex // 锁必须和 count 一起留在同一个对象里
    n  int
}

func (c Counter) Add(delta int) int { // 值接收者会复制整个 Counter，包括 mu
    c.mu.Lock()
    defer c.mu.Unlock() // 解锁的是副本里的 mu
    c.n += delta         // 修改的也是副本里的 n
    return c.n
}

这里即使没有立即死锁，Add 修改的也只是方法参数副本。若结构体里还有指针、切片或 map，复制后的数据可能又与原对象共享底层存储，于是会出现“锁是两把，数据是一份”的更危险组合：两个 goroutine 各自拿着不同的锁，却同时改同一块数据。

排查时先搜索这些复制点：

用指针接收者保留唯一锁实例

修复的核心不是把 Lock 调用挪到别处，而是让所有修改操作都落在同一个地址上。构造函数返回指针，方法也使用指针接收者：

type Counter struct {
    mu sync.Mutex // 零值可用，但使用后不再复制
    n  int
}

func NewCounter() *Counter {
    return &Counter{} // 返回唯一对象，调用方不要再按值拷贝
}

func (c *Counter) Add(delta int) int {
    c.mu.Lock()
    defer c.mu.Unlock() // 无论正常返回还是提前返回都释放同一把锁
    c.n += delta
    return c.n
}

调用方保存的是 *Counter，方法集也会把接收者绑定到这份对象。这里的“唯一”是业务对象生命周期内的唯一锁实例，不代表全局只能有一把锁；如果要隔离两个计数器，就创建两个独立指针对象。

用 go vet 把复制风险挡在提交前

Go 工具链的 copylocks 检查专门提示把锁按值传递的代码。它是启发式检查，不等于程序正确性证明，但适合放进提交前检查：

# 检查当前模块及其子包中可能按值复制锁的代码
go vet ./...

收到报告后不要只在那一行加注释绕过。沿着类型的生命周期往回看：它是否已经调用过 Lock，是否通过值接收者进入方法，是否被放入 map 或从函数按值返回；如果确实需要对外返回内容，优先返回不带锁的数据快照，而不是返回整个同步对象。

一份实用的判断清单

• 看字段：结构体里是否含有 sync.Mutex、sync.RWMutex、sync.Cond 或其他不可复制同步状态。
• 看接收者：只要方法要读写共享字段，就优先使用指针接收者。
• 看容器：range 变量、map value 和 interface 装箱是否把对象变成了值副本。
• 看边界：复制发生在第一次使用前还是之后；即使零值复制暂时可行，也不应把带锁对象设计成可复制 API。
• 看工具：把 go vet ./... 纳入 CI，并把报告当成设计反馈处理。

相关问题

只读方法也必须使用指针接收者吗？

如果方法属于带锁对象，通常仍建议使用指针接收者，避免调用时复制整个对象；读取共享字段时还应遵守同一套同步约束。

把 Mutex 改成指针字段能解决复制吗？

它可能让多个副本共享同一把锁，但也会改变零值可用性和生命周期管理，容易把锁与数据的所有权弄混。更稳妥的做法是直接禁止复制外层对象并使用指针传递。

go vet 没有报告就代表没有并发问题吗？

不是。copylocks 只覆盖一类可疑复制，数据竞争、锁顺序错误和未覆盖的共享字段仍需要通过代码审查与并发测试发现。