Go 复制含 Mutex 的结构体造成异常的规避方式

Go 中包含 sync.Mutex 的结构体应保持对象身份，方法用指针接收者，跨函数传指针，容器优先存指针。锁首次使用后不能复制；即使副本里的锁恰好处于未锁定状态，也不能把它当成一把可独立使用的新锁。修复目标不是“再加一把锁”，而是让受保护数据的所有访问都对应同一个同步对象。

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

以下以批处理计数器为例：并发写入数应等于任务数，不应先拿吞吐量评价错误实现。代码和预期关系是供读者复现的示例，未作为本机运行记录；配图均为静态结构说明。

先区分数据没变与互斥失效

有两个容易混淆的现象：普通整数随结构体被复制后，修改落在副本上，调用方看到原值不变；如果字段里还含 map、slice 或指针，结构体副本又可能引用同一份底层数据，却各自持有不同锁。后者不是“一人一把锁更安全”，而是没有建立保护同一数据所需的共同互斥。

package counter

import "sync"

// 错误示例：值接收者会复制包含锁的整个对象，禁止用于实际并发代码。
type BadCounter struct {
	mu sync.Mutex
	n  int
}

func (c BadCounter) Add() {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.n++ // 修改的是接收者副本，不是调用方的 n。
}

即使写成 c.Add()，调用语法也不会把上面的值接收者变成指针接收者。这个错误片段里的原始 n 不会因副本的自增而变化；不要把它与另一个包含 map 的反例混为一谈，也不要依赖已经复制的锁具有某种确定运行结果。对已用锁的复制违反标准库契约，可能表现为等待、互斥失效或其他异常，不能用“这次没卡住”证明正确。

概念上可把原对象记为“原对象”、其锁记为“原锁”、其整数记为“原计数”；值接收者形成“接收者副本”“副本锁”“副本计数”。两组不是同一个对象。Mutex 源码中的公开契约明确了首次使用后不可复制的要求。

让方法与参数保留同一个对象

package counter

import "sync"

// Counter 一经使用就保持对象身份，所有访问统一使用指针。
type Counter struct {
	mu sync.Mutex
	n  int
}

func New() *Counter { return &Counter{} }

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 // 只返回业务数据，不返回整个 Counter。
}

// Reset 接受原对象地址，不能改成按值传递 Counter。
func Reset(c *Counter) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.n = 0
}

把这段保存为独立包的 counter.go 即可与后面的测试配合。这里 Add、Value 和 Reset 都使用同一对象内的锁。Value 是只读方法也要用指针接收者：只读业务字段不代表可以复制同步字段，且并发读取本身仍要遵守同步规则。

接收者改完还不够。func Save(c Counter)、other := *c、把 *c 放入接口值、返回 Counter 的旧接口，都需要检查是否复制了已经投入使用的对象。构造器返回 *Counter 使默认用法更明确，但 Go 类型系统仍允许显式解引用复制，不能把它称为编译期绝对禁止。

若要快照，应该在锁内读取并构造不带锁的数据对象。前面的整数返回值就是最小例子。如果业务字段以后变为 map 或 slice，返回其头部仍可能泄漏共享存储，需要根据业务做副本；不能机械地返回整个结构体当快照。

容器保存指针，而不是复制工作中的锁

// 片段复用前文的 Counter；初始化完后不再并发修改容器本身。
items := []*Counter{New(), New()}
for _, c := range items {
	c.Add(1) // 这里只复制指针，不复制锁。
}

byName := map[string]*Counter{"export": items[0]}
if c, ok := byName["export"]; ok {
	c.Add(1) // map 取出的仍然是原对象地址。
}

// 需要新增元素时，复制的是指针；共享追加仍须另外同步。
items = append(items, New())

这是一段放进调用函数内的用法片段，不是独立 main 程序。指针列表与按名称索引可以共同引用一个 Counter，目标是“同一份计数配同一把锁”。图中的“指针列表”“名称索引”“共享计数器”“成员锁”“计数字段”“方法集合”对应这套模型。

按索引调用 values[i].Add(1) 可以避开 range 的元素副本，但不能解决后续 append 扩容搬移已用元素的风险。切片稳定且不再扩容是另一种受约束的设计，不应随手推广成“切片存锁值没有问题”。Go 1.22 的循环变量规则变化也没有把结构体元素变成引用。

此外，元素内的锁不保护容器自身：多个 goroutine 同时追加列表或读写普通 map，仍须单独同步容器结构，或者初始化后保持只读。复制指针不复制锁，不代表 map、slice 或对象公开字段自动具备并发安全。这里的值复制和迭代语义可参阅 Go 语言规范。

noCopy 是静态提醒，不是运行时保护

标准库内部的 noCopy 不是可直接导入的公共类型。它使用空的指针方法为静态工具提供识别线索；项目若确有身份不可复制的类型，可使用类似的本地约定。已经含 sync.Mutex 的类型通常不必额外重复放一份 noCopy 才能获得 copylocks 提示。

package identity

// noCopy 只为静态工具提供方法形状，不实现真正的互斥。
type noCopy struct{}
func (*noCopy) Lock()   {}
func (*noCopy) Unlock() {}

// 用命名字段，不匿名嵌入，避免把空 Lock/Unlock 提升为业务方法。
type Handle struct {
	noCopy noCopy
	id     string
}

func New(id string) *Handle { return &Handle{id: id} }
func (h *Handle) ID() string { return h.id }

这段与 counter 是两个独立包，不要拼进同一个 Go 源文件。命名字段避免将空的 Lock/Unlock 提升到 Handle 的方法集；这些空方法没有加锁能力。noCopy 不是 Go 关键字，不会让赋值语句被编译器一律拒绝，也不会在复制发生时自动 panic。

标准库中的 noCopy 定义与 copylock 分析器说明可帮助理解这种约定。工具提示可辅助维护，但“没提示”不等于所有共享状态都安全。

用可复现计数衡量修复，再看性能

对前面的 Counter，可以先设定明确正确性指标：8 个 goroutine，各自加 1000 次，最终应为 8000。这个 8000 是测试输入推导的期望，不是已采集的性能或线上数据。将下面代码保存为同包 counter_test.go：

package counter

import (
	"sync"
	"testing"
)

func TestSharedCounter(t *testing.T) {
	const workers, each = 8, 1000
	c := New()
	var wg sync.WaitGroup
	for i := 0; i 

# 在你自己的 Go 模块中执行，本文未运行这些命令。
go vet -copylocks ./...
# 对修正后的计数器运行并发检测与重复计数测试。
go test -race -run TestSharedCounter -count=20 ./...

前一条用于发现可识别的锁复制位置；后一条用于在实际执行路径中观察数据竞争和断言。它们是读者的测试方法，不是本次发布前执行的校验。race 检测只覆盖被执行的路径，也不是通用死锁证明器。值接收者只改副本的错误可能没有共享写冲突，却仍然违反业务预期，所以最终计数断言不能省略。

如果后续确实需要性能对比，应固定 Go 工具链、硬件、并发数与任务量，分别记录耗时、分配与竞争情况。本次没有进行压测，因此不提供提速倍数或伪造的基线。指针能维持身份，但也改变别名关系和分配行为，不能直接推导成“必然更快”。

常见问题与迁移取舍

从没用过的零值 Mutex 也绝对不能复制吗？

Mutex 文档明确禁止的是首次使用后的复制。但工程接口通常从构造起就采用不可复制约定，避免调用方必须追踪每个实例是否已经使用。这里的建议比最低契约更保守，不是把文档改成“任何零值复制都会失败”。

把 Mutex 字段改成指针能直接解决吗？

不宜只改锁字段。锁指针共享、普通整数却分别复制，可能形成锁共享但数据不共享的奇怪模型，还增加初始化与 nil 风险。更直观的做法是整体传对象指针；若需要独立副本，应显式创建新对象并在同步保护下复制业务数据，不复制锁状态。

如何安排已有项目的改动？

先确定共享对象的创建与持有者，再统一方法接收者与函数签名，最后调整容器元素类型和快照出口。检查重点是每条访问路径是否保留同一个锁与数据组合，而不是仅让某一行工具提示消失。