Go 并发进阶：sync.Cond 条件变量与互斥锁的协作精髓

关键解析：Wait() 的底层逻辑

调用 Wait() 时，协程会做三件事：

1. 释放当前持有的互斥锁；
2. 阻塞等待，直到收到 Signal/Broadcast 通知；
3. 被唤醒后，重新获取互斥锁，然后继续执行。

这也是为什么 Wait() 必须在'持有锁'的状态下调用——如果不持有锁，'释放锁'的操作就会 panic。

三、实战：用 sync.Cond 实现'信箱收发情报'

结合前文的'信箱场景'，我们用代码实现完整的协程协作逻辑，拆解每一步的核心要点。

1. 定义核心变量

package main

import (
	"log"
	"sync"
	"time"
)

// 信箱：0=空，1=有情报
var mailbox uint8

// 读写锁：保护 mailbox 的访问
var lock sync.RWMutex

// 条件变量：通知'可以放情报'（绑定写锁）
var sendCond = sync.NewCond(&lock)

// 条件变量：通知'可以取情报'（绑定读锁）
var recvCond = sync.NewCond(lock.RLocker())

2. 实现'放情报'协程（写操作）

// 放情报的协程
func sender(max int, wg *sync.WaitGroup) {
	defer wg.Done()
	for i := 1; i <= max; i++ {
		time.Sleep(time.Millisecond * 500) // 模拟业务耗时

		// 1. 持有写锁（保护 mailbox）
		lock.Lock()

		// 2. 检查状态：信箱非空则等待（必须用 for，而非 if！）
		for mailbox == 1 {
			sendCond.Wait() // 释放锁并等待通知，被唤醒后重新获取锁
		}

		// 3. 状态满足，操作共享资源
		mailbox = 1
		log.Printf("发送者 [%d]：情报已放入信箱", i)

		// 4. 释放写锁
		lock.Unlock()

		// 5. 通知取情报的协程：状态已变更
		recvCond.Signal()
	}
}

3. 实现'取情报'协程（读操作）

// 取情报的协程
func receiver(max int, wg *sync.WaitGroup) {
	defer wg.Done()
	for i := 1; i <= max; i++ {
		time.Sleep(time.Millisecond * 500) // 模拟业务耗时

		// 1. 持有读锁（保护 mailbox）
		lock.RLock()

		// 2. 检查状态：信箱为空则等待（同样用 for）
		for mailbox == 0 {
			recvCond.Wait() // 释放读锁并等待通知
		}

		// 3. 状态满足，操作共享资源
		mailbox = 0
		log.Printf("接收者 [%d]：情报已从信箱取走", i)

		// 4. 释放读锁
		lock.RUnlock()

		// 5. 通知放情报的协程：状态已变更
		sendCond.Signal()
	}
}

4. 主函数执行

func main() {
	var wg sync.WaitGroup
	max := 5 // 收发次数
	wg.Add(2)

	// 启动协程
	go sender(max, &wg)
	go receiver(max, &wg)

	// 等待协程结束
	wg.Wait()
	log.Println("任务完成：所有情报已收发完毕")
}

核心细节解析

（1）为什么用 for 循环检查状态，而非 if？

这是 sync.Cond 使用中最容易踩坑的点！ Wait() 被唤醒后不代表状态一定满足（可能存在'虚假唤醒'，或多个协程被 Broadcast 唤醒后抢占资源）。比如：多个取情报的协程被唤醒，其中一个协程先获取锁并取走情报，其他协程再获取锁时，信箱已空——如果用 if，会直接执行后续操作，导致逻辑错误；而 for 循环会重新检查状态，不满足则继续等待。

（2）读写锁与条件变量的配合逻辑

示例中 sendCond 绑定写锁（对应'放情报'的写操作），recvCond 绑定读锁（对应'取情报'的读操作），既保证了共享资源的安全，又利用读写锁的特性提升了读操作的并发度（如果有多个'读情报'的协程，读锁可并发持有）。

（3）Signal() 为什么要在解锁后调用？

虽然 Signal()/Broadcast() 在锁内调用也不会 panic，但解锁后调用更高效：如果在锁内调用，被唤醒的协程会立刻尝试获取锁，但此时锁还未释放，协程会再次阻塞；解锁后调用，被唤醒的协程可以直接获取锁，减少上下文切换。

四、常见问题解答

1. *sync.Cond 和 sync.Cond 能否传递？

• *sync.Cond（指针类型）：可以安全传递。因为 sync.Cond 的方法都是指针方法，且指针传递不会拷贝底层的锁和通知队列，协程间共享同一个条件变量实例；
• sync.Cond（值类型）：禁止传递/拷贝。sync.Cond 包含 noCopy 字段（编译期检查拷贝），拷贝后会导致多个实例绑定同一个锁，引发通知逻辑混乱，甚至 panic。

2. sync.Cond 对比 Channel，该怎么选？

• 用 Channel：适合'一对一'或'一对多'的简单通知（比如用无缓冲 Channel 做信号量），Go 官方更推荐优先用 Channel 实现协作；
• 用 sync.Cond：适合'多对多'的复杂场景（比如多个协程等待同一个状态变更，需要批量唤醒），或需要'广播通知'的场景，比 Channel 更轻量。

3. 读写锁的读锁内修改资源，为什么没问题？

示例中'取情报'协程持有读锁时，将 mailbox 置为 0（写操作），看似违背'读锁只读'的原则，实则是场景简化的设计： 实际业务中，若多个协程同时'取情报'，需改用写锁；示例中仅一个取情报协程，读锁仅用于配合条件变量演示，核心是理解'条件变量与读锁的绑定方式'。

五、总结

sync.Cond 的核心价值是'高效等待状态变更'，其与互斥锁的配合可总结为三句话：

1. 初始化必绑定互斥锁（sync.Locker 实现）；
2. Wait() 必在'持有锁'时调用，且用 for 循环检查状态；
3. Signal/Broadcast 必在'释放锁'后调用，减少阻塞。

在并发编程中，当你需要'等待共享资源状态满足后再操作'时，sync.Cond 能避免轮询带来的性能损耗，让协程协作更优雅。掌握它与互斥锁的配合逻辑，能让你的 Go 并发代码更健壮、更高效。

拓展思考：如果需要唤醒所有等待的协程（比如多个协程等待同一个信箱），该如何修改代码？（提示：用 Broadcast() 替代 Signal()）