GoLang并发编程中条件变量sync.Cond的使用

一、条件变量与互斥锁

• 条件变量是基于互斥锁的，它必须基于互斥锁才能发挥作用；

• 条件变量并不是用来保护临界区和共享资源的，它是用来协调想要访问共享资源的那些线程的；

• 在Go语言中，条件变量最大的优势是效率方面的提升。当共享资源不满足条件的时候，想操作它的线程不用循环往返地检查了，只要等待通知就好了。

二、条件变量与互斥锁的配合使用

条件变量的初始化离不开互斥锁，并且它的方法有点也是基于互斥锁的。

条件变量提供的三个方法：等待通知（wait）、单发通知（signal）、广发通知（broadcast）。

三、条件变量的使用

创建锁和条件

// mailbox 代表信箱
// 0 代表信箱是空的，1代表信箱是满的
var mailbox uint8
// lock 代表信箱上的锁
var lock sync.RWMutex
// sendCond 代表专用于发信的条件变量
var sendCond = sync.NewCond(&lock)
// reveCond 代表专用于收信的条件变量
var reveCond = sync.NewCond(lock.RLocker())

• sync.Cond类型并不是开箱即用的，只能利用sync.NewCond创建它的指针值。这个函数需要sync.Locker类型的参数值。

• sync.Locker是一个接口，它包含两个指针方法，即Lock()和Unlock()；因此，sync.Mutex 和sync.RWMutex这两个类型的指针类型才是sync.Locker接口的实现类型。

• 上面lock变量的Lock方法和Unlock方法分别用于对其中写锁的锁定和解锁，它们与sendCond变量的含义对应。

• lock.RLocker()得到的值，拥有Lock和Unlock方法，其内部会分别调用lock变量的RLock方法和RUnlock方法；

使用

lock.Lock()
for mailbox == 1 {
sendCond.Wait()
}
mailbox = 1
lock.Unlock()
recvCond.Signal()

lock.RLock()
for mailbox == 0 {
recvCond.Wait()
}
mailbox = 0
lock.RUnlock()
sendCond.Signal()

完整代码：

package main
import (
"log"
"sync"
"time"
)
func main() {
// mailbox 代表信箱
// 0 代表信箱是空的，1代表信箱是满的
var mailbox uint8
// lock 代表信箱上的锁
var lock sync.RWMutex
// sendCond 代表专用于发信的条件变量
var sendCond = sync.NewCond(&lock)
// reveCond 代表专用于收信的条件变量
var reveCond = sync.NewCond(lock.RLocker())
// sign 用于传递演示完成的信号
sign := make(chan struct{}, 2)
max := 5
go func(max int) { // 用于发信
defer func() {
sign <- struct{}{}
}()
for i := 1; i <= max; i++ {
time.Sleep(time.Millisecond * 5)
lock.Lock()
for mailbox == 1 {
sendCond.Wait()
}
log.Printf("sender [％d]: the mailbox is empty.", i)
mailbox = 1
log.Printf("sender [％d]: the letter has been sent.", i)
lock.Unlock()
reveCond.Signal()
}
}(max)
go func(max int) { // 用于收信
defer func() {
sign <- struct{}{}
}()
for j := 1; j <= max; j++ {
time.Sleep(time.Millisecond * 500)
lock.RLock()
for mailbox == 0 {
reveCond.Wait()
}
log.Printf("receiver [％d]: the mailbox is full.", j)
mailbox = 0
log.Printf("receiver [％d]: the letter has been received.", j)
lock.RUnlock()
sendCond.Signal()
}
}(max)
<-sign
<-sign
}

四、条件变量的Wait方法做了什么

（1）条件变量Wait方法主要做的四件事

条件变量的Wait方法主要做了四件事：

• 把调用它的goroutine（也就是当前goroutine）加入到当前条件变量的通知队列中；

• 解锁当前条件变量基于的那个互斥锁；

• 让当前的goroutine处于等待状态，等到通知到来时再决定是否唤醒它。此时，这个goroutine就会阻塞在调用这个Wait方法的那行代码上；

• 如果通知到来并决定唤醒这个goroutine，那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此以后，当前的goroutine就会继续执行后面的代码了。

（2）为什么要先要锁定条件变量基于的互斥锁，才能调用它的wait方法

因为条件变量的wait方法在阻塞当前的goroutine之前，会解锁它基于的互斥锁。所以在调用wait方法之前，必须先锁定这个互斥锁，否则在调用这个wait方法时，就会引发一个不可恢复的panic。

如果条件变量的Wait方法不先解锁互斥锁的话，那就会造成两个后果：不是当前的程序因panic而崩溃，就是相关的goroutine全面阻塞。

（3）为什么用for语句来包裹调用的wait方法表达式，用if语句不行吗

if语句只会对共享资源的状态检查一次，而for语句却可以做多次检查，直到这个状态改变为止。

之所以做多次检查，主要是为了保险起见。如果一个goroutine因收到通知而被唤醒，但却发现共享资源的状态，依然不符合它的要求i，那么就应该再次调用条件变量的Wait方法，并继续等待下次通知的到来。

这种情况是很有可能发生的，具体如下面所示：

• 有多个 goroutine 在等待共享资源的同一种状态。比如，它们都在等mailbox变量的值不为0的时候再把它的值变为0，这就相当于有多个人在等着我向信箱里放置情报。虽然等待的 goroutine 有多个，但每次成功的 goroutine 却只可能有一个。别忘了，条件变量的Wait方法会在当前的 goroutine 醒来后先重新锁定那个互斥锁。在成功的 goroutine 最终解锁互斥锁之后，其他的 goroutine 会先后进入临界区，但它们会发现共享资源的状态依然不是它们想要的。这个时候，for循环就很有必要了。

• 共享资源可能有的状态不是两个，而是更多。比如，mailbox变量的可能值不只有0和1，还有2、3、4。这种情况下，由于状态在每次改变后的结果只可能有一个，所以，在设计合理的前提下，单一的结果一定不可能满足所有 goroutine 的条件。那些未被满足的 goroutine 显然还需要继续等待和检查。

• 有一种可能，共享资源的状态只有两个，并且每种状态都只有一个 goroutine 在关注，就像我们在主问题当中实现的那个例子那样。不过，即使是这样，使用for语句仍然是有必要的。原因是，在一些多 CPU 核心的计算机系统中，即使没有收到条件变量的通知，调用其Wait方法的 goroutine 也是有可能被唤醒的。这是由计算机硬件层面决定的，即使是操作系统（比如 Linux）本身提供的条件变量也会如此。

综上所述，在包裹条件变量的Wait方法的时候，我们总是应该使用for语句。

不要用if语句，因为它不能重复地执行&ldquo;检查状态 - 等待通知 - 被唤醒&rdquo;的这个流程。

（4）条件变量的Signal方法和Broadcast方法

条件变量signal方法和Broadcast方法都是用来发送通知的，不同的是，前者的通知只会唤醒一个因此而等待的goroutine，而后者的通知却会唤醒所有为此等待的goroutine。

条件变量的Wait方法总会把当前的 goroutine 添加到通知队列的队尾，而它的Signal方法总会从通知队列的队首开始，查找可被唤醒的 goroutine。所以，因Signal方法的通知，而被唤醒的 goroutine 一般都是最早等待的那一个。

条件变量Signal方法和Broadcast方法放置的位置：

与Wait方法不同，条件变量的Signal方法和Broadcast方法并不需要在互斥锁的保护下执行。恰恰相反，我们最好在解锁条件变量基于的那个互斥锁之后，再去调用它的这两个方法。这更有利于程序的运行效率。

条件变量的通知具有即时性：

如果发送通知的时候没有 goroutine 为此等待，那么该通知就会被直接丢弃。在这之后才开始等待的 goroutine 只可能被后面的通知唤醒。

来源：https://blog.csdn.net/hefrankeleyn/article/details/128602812