Go 复制 Mutex 为什么会造成锁失效

如果一个包含 sync.Mutex 的结构体被复制，最容易出现的误判是：“字段里还是 Mutex，所以锁仍然有效。”实际上，复制得到的是另一个锁实例。若两个结构体副本又指向同一份底层数据，就会变成两把互不认识的锁同时保护同一个对象，互斥关系随之失效。

Go 官方 sync 文档明确写着：Mutex 的零值是未上锁状态，但首次使用后不能复制。本文只围绕这个规则解释值接收者、结构体赋值和返回值为什么危险，以及如何把锁的所有权固定在同一个对象上。

先看清 Mutex 保护的是哪个实例

Mutex 的互斥不是一个类型名称带来的全局能力，而是绑定在某个具体实例上。对同一个实例调用 Unlock 后，后续对该实例的 Lock 才能建立同步关系；把结构体复制一份，复制出的字段也代表另一份锁状态。

下面这个写法看起来像是在给 Cache 加锁，实际每次调用都会把接收者复制一份：

type Cache struct {
	mu   sync.Mutex
	data map[string]int
}

// Put 使用值接收者，会在进入方法前复制整个 Cache。
// 复制后的 mu 与调用方的 mu 不是同一个锁实例。
func (c Cache) Put(key string, value int) {
	c.mu.Lock()
	defer c.mu.Unlock() // 只解锁本次方法拿到的副本
	c.data[key] = value
}

即使调用方变量是可取地址的，值接收者也不会自动变成指针接收者。真正需要共享锁时，方法签名必须明确写出指针：

// PutPtr 通过指针接收者共享原始 Cache 和原始 Mutex。
// defer 保证发生返回或错误路径时仍会释放同一个锁实例。
func (c *Cache) PutPtr(key string, value int) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.data[key] = value
}

结构体复制后，为什么风险可能更隐蔽

如果结构体里只有整数等值字段，复制后通常只是操作了另一份数据；但 map、slice、指针或接口字段可能仍然指向同一份底层对象。此时“数据看起来共享，锁却已经分裂”，风险就从结果不更新变成了真正的并发保护缺口。

type Cache struct {
	mu   sync.Mutex
	data map[string]int
}

// Add 复制了 Cache：mu 被复制，data 的 map header 也被复制，
// 但两个 header 仍可能指向同一个底层 map。
func (c Cache) Add(key string) {
	c.mu.Lock() // 可能只锁住副本的 Mutex
	defer c.mu.Unlock()
	c.data[key]++ // 共享底层 map 可能被另一把锁同时修改
}

// NewCache 返回指针，调用方后续只围绕同一个对象传递引用。
func NewCache() *Cache {
	return &Cache{data: make(map[string]int)}
}

这里不能把问题简单归结为“map 不能并发写”。更准确的判断是：保护 map 的锁必须也是共享的。若调用路径上出现 Cache 的值传递、赋值或返回值复制，两个 goroutine 可能分别拿到 Mutex A 和 Mutex B，它们都认为自己已经获得保护，但这两把锁之间没有互斥关系。

哪些写法会在不经意间复制 Mutex

排查时不要只搜索 sync.Mutex 的声明，还要沿着类型的传递路径检查复制点。常见位置有四类：

尤其要注意“构造阶段复制”和“首次使用后复制”的区别。零值 Mutex 可以直接使用，但一旦某个实例已经参与加锁，再通过赋值、返回或值接收者复制它，就违反了官方约束。调用者不要依赖复制后的锁状态来推断原对象是否上锁。

把锁和数据放进同一个稳定所有权

修复的核心不是给每个副本再加一把锁，而是让受保护数据与负责保护它的 Mutex 处在同一个稳定对象中，并让调用链传递这个对象的指针。

type Counter struct {
	mu    sync.Mutex
	value int
}

// Increment 只接收 *Counter，避免复制已经使用过的 Mutex。
func (c *Counter) Increment() int {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.value++
	return c.value
}

// Read 读取同一对象中的 value，读写都使用同一个 Mutex。
func (c *Counter) Read() int {
	c.mu.Lock()
	defer c.mu.Unlock()
	return c.value
}

如果对象需要复制业务快照，应定义一个不带锁的快照类型，逐字段提取数据，而不是直接复制整个带锁结构体：

type CounterSnapshot struct {
	Value int
}

// Snapshot 在锁内读取数据，只返回独立的业务快照。
// 返回值不包含 Mutex，因此不会把锁带出对象所有权边界。
func (c *Counter) Snapshot() CounterSnapshot {
	c.mu.Lock()
	defer c.mu.Unlock()
	return CounterSnapshot{Value: c.value}
}

代码评审时用这份清单收口

看到一个带 sync.Mutex 的类型，可以按下面顺序检查：

1. 方法接收者是不是值类型；只要方法会读写受保护数据，优先要求指针接收者。
2. 函数参数、返回值和局部赋值是否传递了完整结构体；重点搜索按值传参和结构体赋值。
3. 锁保护的字段是否包含 map、slice、指针或接口；这些字段复制后可能仍共享底层对象。
4. 是否需要对外复制；如果需要，设计不含锁的快照或复制方法，把锁留在原对象内。
5. 是否让读写路径都使用同一个对象；不要让调用方自己创建“看起来相同”的第二把锁。

一句话总结：Mutex 不是可以随结构体自由复制的普通字段。只要它已经开始参与同步，就要把它和受保护数据视为一个不可复制的所有权单元；使用指针接收者、指针返回值和无锁快照，才能让“加锁”真正落在共享对象上。

常见追问

Mutex 复制后一定会立刻 panic 吗？

不一定。复制本身可能没有即时错误，但复制出的锁实例不再与原实例共享同步状态，后续并发行为就可能错误。

只复制一个还没用过的 Mutex 可以吗？

应把它限定在构造阶段，并保证后续只使用最终实例。工程代码更稳妥的做法是从一开始就固定指针所有权，避免未来在调用链中误复制。

为什么指针接收者就能解决问题？

指针接收者让方法操作调用方持有的原始结构体，因此 Lock、Unlock 和受保护字段落在同一个对象上；它不能替你修复显式的结构体赋值，复制点仍需单独清理。

参考：https://pkg.go.dev/sync；https://go.dev/ref/mem