Go sync.Cond 首次使用后为什么不能复制

我在把并发组件收进一个业务结构体时，最容易忽略的不是锁怎么加，而是这个结构体能不能被复制。sync.Cond 就属于需要特别标记的类型：它可以在首次使用前完成配置，但一旦已经参与过等待或通知，就不应再通过赋值、按值传参或容器复制制造第二份。

记住一条实用规则：包含 sync.Cond 的类型通常用指针传递；如果确实需要复制，只能在它第一次使用之前完成，而且复制后要把它当成独立的、尚未使用的实例。

先区分“配置完成”和“已经使用”

Go 官方文档对 sync.Cond 有一个很容易被忽略的生命周期要求：它有一个关联的 Locker，通常是 *sync.Mutex 或 *sync.RWMutex；同时，Cond 在第一次使用后不能再被复制。

这里的关键不是“结构体里出现了指针，所以怎么复制都没关系”。复制 Cond 本身会复制它的外层值和内部并发状态，而 L 只是其中的一个关联锁。复制完成后，两个 Cond 可能仍然指向同一个 Locker，却各自拥有不同的等待状态，这就不再是一个完整的条件变量。

因此，初始化阶段和运行阶段要分开看。下面的写法在首次使用前复制，语义上仍是两个尚未运行的实例；但复制后只要其中一个开始参与并发流程，就不应再把它当成普通值继续搬运。

package main

import "sync"

type gate struct {
	mu   sync.Mutex
	cond sync.Cond
}

func newGate() *gate {
	g := &gate{}
	// 先固定 Locker，再把整个并发对象交给后续方法使用。
	g.cond = *sync.NewCond(&g.mu)
	return g
}

func main() {
	original := newGate()
	// 这里只展示初始化完成后的独立对象；业务代码不要复制已使用的 gate。
	_ = original
}

示例里的 NewCond 返回指针，赋给字段时使用的是初始化阶段的值。真正进入并发流程后，gate 应该由指针持有和传递，而不是把它当作轻量配置结构体。

为什么复制后会让等待状态失去一致性

Cond.Wait 会围绕关联的锁完成“释放、等待、重新获得”的协调；Signal 和 Broadcast 则根据 Cond 的等待状态决定唤醒对象。这个关系要求：观察条件、修改条件、等待和通知都围绕同一个 Cond 与同一个 Locker 组织。

如果在首次使用后复制，原对象和副本看起来都带有一个 L，但它们内部的等待登记并不会因为复制就重新建立一套有意义的同步协议。一个 goroutine 可能在原对象上等待，另一个调用方却拿着副本发送通知；即使两者共享底层互斥锁，也不能把两份 Cond 当作同一个等待集合。

最容易发生的三种隐式复制

第一种是结构体赋值。只要并发对象已经启动，copy := *original 就会复制整个对象；把它放进另一个业务结构体也会触发同样的问题。

第二种是按值传参或按值返回。代码读起来像普通配置转换，但函数边界已经产生了一份副本。第三种是把包含 Cond 的元素放入需要搬运元素的容器，或在扩容、排序、交换时让值发生移动。

type queue struct {
	mu    sync.Mutex
	ready *sync.Cond
	items []string
}

func newQueue() *queue {
	q := &queue{}
	// 让 Cond 与 queue 的互斥锁绑定，并只把 queue 指针交给调用方。
	q.ready = sync.NewCond(&q.mu)
	return q
}

func add(q *queue, item string) {
	q.mu.Lock()
	defer q.mu.Unlock() // 无论后续是否扩展逻辑，都保证释放互斥锁。

	q.items = append(q.items, item)
	// 通知发生在同一个 Cond 上，避免把副本误当成原队列的通知中心。
	q.ready.Signal()
}

这里的重点不是 Signal 一定要由某个固定位置调用，而是整个队列的所有权是稳定的：queue 通过指针传递，ready 与 mu 属于同一个对象。若需要复制业务配置，应把配置与运行中的队列状态拆开，不要复制已经工作的 Cond。

代码评审时怎么快速判断是否安全

我通常按下面的顺序看：先搜索包含 sync.Cond 的结构体，再检查它是否有值接收者、按值返回、显式结构体赋值和会搬运元素的容器操作；最后确认构造函数是否返回指针，以及 NewCond 使用的 Locker 是否属于同一个长期存活的对象。

结论与常见问题

sync.Cond 不是普通的可复制配置值。首次使用前可以完成 Locker 绑定和对象初始化；进入并发运行阶段后，要把它视为带生命周期的同步原语。最稳妥的工程约定是：包含 Cond 的对象不提供值语义，构造函数返回指针，方法使用指针接收者，复制需求则放在不含同步状态的纯数据结构上。

只复制包含 Cond 的结构体，但没有 goroutine 在等待，可以吗？

不建议依赖“当前刚好没有等待者”来判断。官方约束针对首次使用后的 Cond，复制边界应由类型生命周期决定，而不是由某一刻的等待数量决定。

为什么共享同一个 Mutex 还不够？

Mutex 只保护共享条件的访问；Cond 还维护与等待和通知相关的同步状态。两个 Cond 即使指向同一把锁，也不是同一个等待集合。

业务对象必须复制时怎么办？

把可复制字段与 Cond、Mutex 等运行态字段分开。复制纯数据，再为新的业务对象重新构造自己的 Locker 和 Cond；不要复制已经使用过的同步对象。