Go sync.Mutex 被复制后为什么会出现不可预测阻塞

我第一次遇到这类问题时，表面现象很像普通锁竞争：某个 goroutine 卡在 Lock()，日志却看不出哪一段代码长期持锁。最后定位到的不是锁粒度，而是一个已经用过的 sync.Mutex 被结构体复制了。Go 官方文档的规则很直接：包含同步类型的值在首次使用后不能再复制。

复制后的对象拥有另一份锁状态。它可能把“已锁定”状态带到副本，造成永久等待；也可能让两个对象分别保护两份业务字段，导致互斥关系失效。修复的核心是让锁和被保护字段始终属于同一个对象，并避免值接收者复制它。

复制发生后，业务字段和锁状态为什么会分裂

Mutex 不是一个可以随意复制的“配置值”。结构体赋值会把整个结构体按值拷贝，里面的锁字段也随之得到一份副本。若复制发生在首次使用之后，副本的内部状态与原对象不再代表同一个临界区。

最危险的时间点是锁仍处于占用状态时复制。副本可能从“锁已被占用”的状态开始，之后对副本调用 Lock 就一直等待一个不会由原对象释放的状态。即使复制时看起来是空闲的，也不能因此放心：原对象和副本已经变成两把不同的锁，分别操作不同副本中的字段时，原本想建立的互斥关系就不存在了。

值接收者会悄悄复制包含锁的结构体

下面的写法容易被忽略，因为调用形式看起来和普通方法一样：

type Counter struct {
    mu    sync.Mutex
    value int
}

// 值接收者会复制整个 Counter，也会复制其中的 Mutex。
func (c Counter) Add() {
    c.mu.Lock()
    defer c.mu.Unlock() // 确保当前副本的锁能释放
    c.value++           // 修改的是副本，调用者看不到这次修改
}

这里有两层问题：每次调用都复制一把锁，而且 value 也在副本里变化，调用者的计数不会按预期累加。改成指针接收者后，锁和字段会留在同一个 Counter 中：

// 指针接收者让方法操作调用者持有的同一个对象。
func (c *Counter) Add() {
    c.mu.Lock()
    defer c.mu.Unlock() // 无论函数如何返回，都释放同一把锁
    c.value++
}

按复制入口排查，而不是只盯着 Lock 调用

代码审查可以先运行下面的检查。它不是并发正确性的证明，但能把常见的复制锁风险尽早暴露出来：

# 在模块根目录检查可能复制 Mutex、RWMutex 等同步值的代码
go vet ./...

修复后不要只看一次“程序没卡住”。应让多个 goroutine 反复调用同一个指针对象，检查最终计数与预期一致，并用超时保护测试，避免错误锁状态让测试永久等待。若还要判断数据竞争，再单独运行 go test -race ./...；它与复制锁检查解决的是不同问题。

相关问题

复制一个从未使用过的 Mutex 也一定错误吗？

官方规则的关键边界是“首次使用后不能复制”。工程上仍建议让包含锁的对象保持稳定身份，避免未来在首次使用前后出现不同语义。

为什么加了 Mutex 仍然会有数据竞争？

如果不同 goroutine 拿到的是不同结构体副本，它们锁住的不是同一把锁；另外，未受该锁保护的读写也不会自动变安全。

出现永久阻塞时先改成 TryLock 吗？

不建议把 TryLock 当作掩盖问题的补丁。先找出复制入口，恢复单一对象和单一锁的关系，再根据业务决定是否需要非阻塞策略。

判断这类故障时，先画出“结构体—锁—共享字段”的所有权关系通常比盯着某一次堆栈更快。只要包含 sync.Mutex 的对象需要跨函数或 goroutine 传递，就优先传指针，并把 go vet 和带超时的并发测试放进日常检查。