Go语言 sync.Cond 使用与原理详解

sync.Cond 的基本概念与应用场景

sync.Cond 表示条件变量，是一种用于协调多个 goroutine 同步执行的机制。当共享资源的状态发生变化时，可以通过条件变量通知所有正在等待该条件的 goroutine 去重新获取资源。

适用场景

在处理多路并发任务时，常常出现某些协程因前置条件不满足而需要阻塞等待的情况。例如，一个耗时较长的数据生产流程完成后，需要唤醒所有已就绪的数据消费协程。虽然许多并发问题可以使用 channel 解决，且 Channel 往往更直观，但在以下场景中，sync.Cond 具有独特优势：

• 需要基于复杂的条件判断来唤醒协程，而非简单的消息传递。
• 需要多次执行“等待”和“通知”操作。Channel 关闭后无法再次打开进行通知，而 Cond 可以反复使用。

sync.Cond 的核心操作方法

sync.Cond 的使用相对简单，主要通过以下三个方法配合完成协作：

1. 创建实例：NewCond

通过 sync.NewCond(l Locker) 方法创建条件变量。参数必须实现 Locker 接口，通常传入 &sync.Mutex{} 或 &sync.RWMutex{}。这个锁对象专门用于保护条件变量的状态及临界区代码的执行。

2. 等待条件：Wait

c.Wait() 方法用于让当前 goroutine 进入阻塞等待状态。它是原子操作，内部会先释放关联的锁，然后挂起当前协程；直到被其他协程通过 Signal 或 Broadcast 唤醒后，它会重新获取锁，然后才返回。

使用时必须遵循以下规范：

1. 调用 Wait 前必须先对锁加锁。
2. 必须在循环中检查条件（使用 for 而非 if）。

标准示例代码如下：

c.L.Lock()
for !condition() {
    c.Wait()
}
// ...条件满足，执行相关逻辑...
c.L.Unlock()

注意：之所以要用 for 循环检查条件，是因为被唤醒的 goroutine 可能会面临“虚假唤醒”，或者在被唤醒到重新获取锁之间，其他协程已经改变了条件。直接 break 跳出会导致错误执行。

3. 发出通知：Signal 与 Broadcast

• Signal()：随机选择一个等待在该条件变量上的 goroutine，将其从等待队列移出并唤醒。如果没有等待者，则无操作。
• Broadcast()：唤醒所有等待在该条件变量上的 goroutine。同样，如果没有等待者，则无操作。

代码实战演示

下面通过一个典型的读写协作示例，展示如何使用 sync.Cond 实现生产者-消费者模式的简化版。写线程准备数据，读线程等待数据就绪。

package main

import (
	"fmt"
	"sync"
	"time"
)

var data string
var done bool
var cond *sync.Cond

func writer() {
	fmt.Println("Writer: Start writing...")
	time.Sleep(time.Second) // 模拟耗时操作
	cond.L.Lock()
	data = "Hello World"
	done = true
	fmt.Println("Writer: Done writing.")
	cond.L.Unlock()
	cond.Broadcast() // 广播通知所有读者
}

func reader(id int) {
	fmt.Printf("Reader %d: Waiting for data...\n", id)
	cond.L.Lock()
	// 循环检测条件，防止虚假唤醒
	for !done {
		cond.Wait()
	}
	fmt.Printf("Reader %d: Got data: %s\n", id, data)
	cond.L.Unlock()
}

func main() {
	mutex := &sync.Mutex{}
	cond = sync.NewCond(mutex)

	go writer()
	go reader(1)
	go reader(2)

	time.Sleep(5 * time.Second) // 主协程保持运行以便观察
}

图1：sync.Cond 唤醒等待队列的示意图

运行上述代码将产生类似如下的输出：

Reader 2: Waiting for data...
Reader 1: Waiting for data...
Writer: Start writing...
Writer: Done writing.
Reader 2: Got data: Hello World
Reader 1: Got data: Hello World

为何不只用 Channel？

很多初学者习惯“万物皆 Channel”，但在此类需要复用通知机制的场景下，sync.Cond 更加合适。假设我们需要让多个读者重复读取不断更新的数据，如果使用 Channel：

1. 关闭 Channel 方式：只能触发一次广播。一旦 close(ch)，所有的接收端解除阻塞，后续再想通过关闭 Channel 来通知新数据是不可能的（导致 Panic）。
2. 发送数据方式：需要提前知道读者数量，向 Channel 发送对应数量的占位符。这不仅增加了内存开销，还使得代码逻辑变得脆弱和复杂。

而 sync.Cond 只要配合 Lock/Unlock 和循环检测，就能无限次地实现“等待 - 修改 - 唤醒”的闭环。

sync.Cond 的内部实现原理

理解了 API 的使用方法后，深入了解其底层结构有助于编写更健壮的并发代码。Go 源码中 sync.Cond 的结构如下：

type Cond struct {
	noCopy noCopy
	L      Locker
	notify  notifyList
	checker copyChecker
}

notifyList 链表结构

notifyList 是唤醒等待者的核心数据结构，它是一个环形链表：

type notifyList struct {
	wait   uint32
	notify uint32
	lock   mutex
	head   *sudog
	tail   *sudog
}

其中：
- head 和 tail 分别指向阻塞协程列表的头尾节点。
- wait 记录下一个添加的等待者的序列号。
- notify 记录下一个要唤醒的序列号。

唤醒机制 (Signal vs Broadcast)

图2：Signal 与 Broadcast 的唤醒范围区别

底层通过 runtime_notifyListNotifyOne 和 runtime_notifyListNotifyAll 实现唤醒操作。这些函数会在持有内部互斥锁的情况下，遍历链表并将符合条件的 sudog 从等待队列移到可运行队列，从而调度器有机会恢复这些 goroutine 的执行。

copyChecker 防拷贝设计

为了确保并发安全，sync.Cond 禁止在任何方法调用后被复制。如果检测到副本，程序会 Panic。这是为了防止多个独立的副本各自维护一套等待链表，导致死锁或竞态条件。因此，务必确保全局只有一个 sync.Cond 实例。

总结

sync.Cond 是 Go 语言中处理多线程（Goroutine）间条件同步的高效工具。它特别适用于那些依赖共享内存状态变化来决定何时继续执行的场景。掌握其正确使用模式——即始终在循环中检查条件，并在加锁状态下调用 Wait——是避免并发 Bug 的关键。以上就是 Go语言 sync.Cond 使用与原理详解的详细内容，更多关于 Go并发编程的资料请关注本站其它相关文章！