当前位置：首页 > 文章列表 > Golang > Go问答 > Go sync.Mutex 为什么不能复制

Go sync.Mutex 为什么不能复制

来源：17golang原创 2026-11-14 16:27:02 0浏览收藏

Go 官方要求 sync.Mutex 在首次使用后不能复制。互斥关系依赖同一把锁的身份，复制结构体会得到另一份锁状态，无法继续代表原来那把锁。实际写法上，含 Mutex 的共享对象通常通过指针传递，读写方法使用指针接收者，并让同一份数据始终受同一个锁对象保护。

官方地址：https://pkg.go.dev/sync

先用指针方法绑定同一把锁

最小可用的设计是把锁和受保护字段放进一个对象，用指针方法封装访问。下面的 Counter 包含 mu 与 n；Add 和 Value 都使用同一个对象中的 mu，不把整个 Counter 返回给外部。

package main

import (
    "fmt"
    "sync"
)

type Counter struct {
    mu sync.Mutex
    n  int
}

func (c *Counter) Add(delta int) {
    // 指针接收者让每次调用使用同一个对象中的锁。
    c.mu.Lock()
    defer c.mu.Unlock()
    c.n += delta
}

func (c *Counter) Value() int {
    // 读取也遵守相同的锁协议，只返回不含锁的数据。
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.n
}

func main() {
    c := &Counter{}
    var wg sync.WaitGroup
    for i := 0; i

该示例的逻辑结果应为 400：四个协程各累加一百次，等待全部结束再读取。这里给出的是代码推导，不是本地执行记录。示例中 Counter 的零值可用，不需要通过复制另一把 Mutex 来初始化锁。

解释首次使用后禁止复制

Mutex 是有状态的同步对象。不要把它理解成一份“调用 Lock 的配置”，以为复制之后两边仍能共同排队。两个不同 Mutex 对象之间没有因为字段值相似就建立互斥关系。

复制已使用的锁可能把内部状态带进新对象，造成等待无法按原有关系结束。另一方面，即使复制时锁处于未锁定状态，两份锁也不是同一把锁，不能用来共同保护同一份共享数据。问题既有锁状态生命周期，也有数据保护关系，不能仅凭“现在没有上锁”判断可复制。

同一个Counter对象中锁与数据的绑定关系 — 静态结构图：两个指针方法关联同一对象内的 mu 和 n，表达共享锁身份，不表示执行顺序。

官方约束精确到“首次使用后”。独立创建多个全新的零值对象当然可以，每个对象拥有自己的锁与自己的数据。但如果字段里还有 map、slice 或指针，按值复制未必意味着数据独立。工程上让这类对象从构造到使用都通过指针流转，往往比要求所有调用方判断锁是否使用过更清楚。

识别值接收者和按值传递

方法写成值接收者时，调用会复制接收者。下面是需要避免的写法，仅用于说明复制位置：

// 错误示意：值接收者复制 Counter，锁住的是副本。
func (c Counter) AddWrong(delta int) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.n += delta
}

对于这个只含整数的例子，修改的是副本中的 n，原对象不会按预期更新。如果受保护字段换成 map，复制结构体又会保留对同一底层 map 的引用，而锁却变成不同副本；多个调用可能分别拿着自己的锁访问同一份数据。加锁语句存在，并不等于共享数据被同一把锁保护。

隐式复制也出现在按值参数、结构体赋值、把对象值装入接口或容器等位置。把方法改成指针接收者只是其中一部分，还需要保证调用链不再把整个已使用对象按值搬走。

位置	风险	常见处理
值接收者	方法得到结构体副本	使用指针接收者
按值函数参数	参数复制含锁对象	传入对象指针
对象赋值	复制锁与字段	共享指针或构造独立对象
业务快照	整对象返回会携带锁	只复制锁内读取的数据