go并发编程之条件变量sync.Cond实战和原理

1. sync.Cond实战

今天简单聊一聊条件变量（conditional variable）。我们常常会把条件变量这个同步工具拿来与互斥锁一起讨论。实际上，条件变量是基于互斥锁的，它必须有互斥锁的支撑才能发挥作用。
条件变量并不是被用来保护临界区和共享资源的，它是用于协调想要访问共享资源的那些线程的。当共享资源的状态发生变化时，它可以被用来通知被互斥锁阻塞的线程。
用Go语言的条件变量在这里的最大优势就是在效率方面的提升。当共享资源的状态不满足条件的时候，想操作它的线程再也不用循环往复地做检查了，只要等待通知就好了。说到这里，想考考你知道怎么使用条件变量吗？
所以，我们今天的问题就是：条件变量怎样与互斥锁配合使用？这道题的典型回答是：条件变量的初始化离不开互斥锁，并且它的方法有的也是基于互斥锁的。条件变量提供的方法有三个：等待通知（wait）、单发通知（signal）和广播通知（broadcast）。我们在利用条件变量等待通知的时候，需要在它基于的那个互斥锁保护下进行。而在进行单发通知或广播通知的时候，却是恰恰相反的，也就是说，需要在对应的互斥锁解锁之后再做这两种操作。问题解析这个问题看起来很简单，但其实可以基于它,延伸出很多其他的问题。比如，每个方法的使用时机是什么？又比如，每个方法执行的内部流程是怎样的？下面，我们一边用代码实现前面那个例子，一边讨论条件变量的使用。
首先，我们先来创建如下几个变量。

	//  false代表没有使用，true代表已经被使用了。
	var used bool
	//  使用和释放操作的锁。
	var lock sync.RWMutex
	// 放入资源的条件变量。
	pushCond := sync.NewCond(&lock)
	// 获取资源条件变量。
	popCond := sync.NewCond(lock.RLocker())

与sync.Mutex类型和sync.RWMutex类型不同，sync.Cond类型并不是开箱即用的。我们只能利用sync.NewCond函数创建它的指针值。这个函数需要一个sync.Locker类型的参数值。还记得吗？我在前面说过，条件变量是基于互斥锁的，它必须有互斥锁的支撑才能够起作用。因此，这里的参数值是不可或缺的，它会参与到条件变量的方法实现当中。
sync.Locker其实是一个接口，在它的声明中只包含了两个方法定义，即：Lock()和Unlock()。sync.Mutex类型和sync.RWMutex类型都拥有Lock方法和Unlock方法，只不过它们都是指针方法。因此，这两个类型的指针类型才是sync.Locker接口的实现类型。
因为pushCond是写入操作，因此需要把基于lock变量的指针值传给了sync.NewCond函数。相应的，popCond变量代表的是专⻔为获取资源的条件变量。因此，为了初始化popCond这个条件变量，我们需要的是lock变量中的读锁，并且还需要是sync.Locker类型的。我们只要在调用sync.NewCond函数时，传入调用表达式lock.RLocker()的结果值，就可以使该函数返回符合要求的条件变量了。为什么说通过lock.RLocker()得来的值就是lock变量中的读锁呢？实际上，这个值所拥有的Lock方法和Unlock方法，在其内部会分别调用lock变量的RLock方法和RUnlock方法。

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

func main() {

	//  false代表没有使用，true代表已经被使用了。
	var exist bool
	//  使用和释放操作的锁。
	var lock sync.RWMutex
	// 放入资源的条件变量。
	pushCond := sync.NewCond(&lock)
	// 获取资源条件变量。
	popCond := sync.NewCond(lock.RLocker())

	// sign 用于传递演示完成的信号。
	sign := make(chan struct{}, 3)
	max := 6
	go func(max int) {
		defer func() {
			sign <- struct{}{}
		}()
		for i := 1; i <= max; i++ {
			time.Sleep(time.Millisecond * 500)
			lock.Lock()
			for exist == true { // 没取走则等待取走
				pushCond.Wait()
			}
			log.Printf("push [%d]: start.", i)
			exist = true //放入
			log.Printf("push [%d]: end.", i)
			lock.Unlock()
			popCond.Signal()  //通知取走的人
		}
	}(max)
	go func(max int) {
		defer func() {
			sign <- struct{}{}
		}()
		for j := 1; j <= max; j++ {
			time.Sleep(time.Millisecond * 500)
			lock.RLock()
			for exist == false { //没有放入则等待放入
				popCond.Wait()
			}
			log.Printf("pop [%d]: start.", j)
			exist = false //取走
			log.Printf("pop [%d]: end.", j)
			lock.RUnlock()
			pushCond.Signal() //通知放入的人
		}
	}(max)

	<-sign
	<-sign
}

2. sync.Cond原理

2.1 条件变量的Wait方法做了什么？

在了解了条件变量的使用方式之后，你可能会有这么几个疑问。

1. 为什么先要锁定条件变量基于的互斥锁，才能调用它的Wait方法？
2. 为什么要用for语句来包裹调用其Wait方法的表达式，用if语句不行吗？

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

1. 把调用它的goroutine（也就是当前的goroutine）加入到当前条件变量的通知队列中。
2. 解锁当前的条件变量基于的那个互斥锁。
3. 让当前的goroutine处于等待状态，等到通知到来时再决定是否唤醒它。此时，这个goroutine就会阻塞在调用这个Wait方法的那行代码上。
4. 如果通知到来并且决定唤醒这个goroutine，那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此之后，当前的goroutine就会继续执行后面的代码了。

你现在知道我刚刚说的第一个疑问的答案了吗？因为条件变量的Wait方法在阻塞当前的goroutine之前会解锁它基于的互斥锁，所以在调用该Wait方法之前我们必须先锁定那个互斥锁，否则在调用这个Wait方法时，就会引发一个不可恢复的panic。
为什么条件变量的Wait方法要这么做呢？你可以想象一下，如果Wait方法在互斥锁已经锁定的情况下，阻塞了当前的goroutine，那么又由谁来解锁呢？别的goroutine吗？先不说这违背了互斥锁的重要使用原则，即：成对的锁定和解锁，就算别的goroutine可以来解锁，那万一解锁重复了怎么办？由此引发的panic可是无法恢复的。
如果当前的goroutine无法解锁，别的goroutine也都不来解锁，那么又由谁来进入临界区，并改变共享资源的状态呢？只要共享资源的状态不变，即使当前的goroutine因收到通知而被唤醒，也依然会再次执行这个Wait方法，并再次被阻塞。所以说，如果条件变量的Wait方法不先解锁互斥锁的话，那么就只会造成两种后果：不是当前的程序因panic而崩溃，就是相关的goroutine全面阻塞。
再解释第二个疑问。很显然，if语句只会对共享资源的状态检查一次，而for语句却可以做多次检查，直到这个状态改变为止。那为什么要做多次检查呢？这主要是为了保险起⻅。如果一个goroutine因收到通知而被唤醒，但却发现共享资源的状态，依然不符合它的要求，那么就应该再次调用条件变量的Wait方法，并继续等待下次通知的到来。这种情况是很有可能发生的，具体如下面所示。

1. 有多个goroutine在等待共享资源的同一种状态。比如，它们都在等exist变量的值不为false的时候再把它的值变为false，这就相当于有多消费的人等着放入资源。虽然等待的goroutine有多个，但每次成功的goroutine却只可能有一个。别忘了，条件变量的Wait方法会在当前的goroutine醒来后先重新锁定那个互斥锁。在成功的goroutine最终解锁互斥锁之后，其他的goroutine会先后进入临界区，但它们会发现共享资源的状态依然不是它们想要的。这个时候，for循环就很有必要了。
2. 共享资源可能有的状态不是两个（简单true/false），而是更多（1，2，3，4…）。这种情况下，由于状态在每次改变后的结果只可能有一个，所以，在设计合理的前提下，单一的结果一定不可能满足所有goroutine的条件。那些未被满足的goroutine显然还需要继续等待和检查。
3. 有一种可能，共享资源的状态只有两个，并且每种状态都只有一个goroutine在关注，就像我们实现的那个例子那样。不过，即使是这样，使用for语句仍然是有必要的。原因是，在一些多CPU核心的计算机系统中，即使没有收到条件变量的通知，调用其Wait方法的goroutine也是有可能被唤醒的。这是由计算机硬件层面决定的，即使是操作系统（比如Linux）本身提供的条件变量也会如此。
   综上所述，在包裹条件变量的Wait方法的时候，我们总是应该使用for语句。好了，到这里，关于条件变量的Wait方法，我想你知道的应该已经足够多了。

2.2 条件变量的Signal方法和Broadcast方法有哪些异同？

条件变量的Signal方法和Broadcast方法都是被用来发送通知的，不同的是，前者的通知只会唤醒一个因此而等待的goroutine，而后者的通知却会唤醒所有为此等待的goroutine。条件变量的Wait方法总会把当前的goroutine添加到通知队列的队尾，而它的Signal方法总会从通知队列的队首开始查找可被唤醒的goroutine。所以，因Signal方法的通知而被唤醒的goroutine一般都是最早等待的那一个。这两个方法的行为决定了它们的适用场景。如果你确定只有一个goroutine在等待通知，或者只需唤醒任意一个goroutine就可以满足要求，那么使用条件变量的Signal方法就好了。否则，使用Broadcast方法总没错，只要你设置好各个goroutine所期望的共享资源状态就可以。此外，再次强调一下，与Wait方法不同，条件变量的Signal方法和Broadcast方法并不需要在互斥锁的保护下执行。恰恰相反，我们最好在解锁条件变量基于的那个互斥锁之后，再去调用它的这两个方法。这更有利于程序的运行效率。最后，请注意，条件变量的通知具有即时性。也就是说，如果发送通知的时候没有goroutine为此等待，那么该通知就会被直接丢弃。在这之后才开始等待的goroutine只可能被后面的通知唤醒。

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

func main() {
	//  false代表没有使用，true代表已经被使用了。
	var exist bool
	//  使用和释放操作的锁。
	var lock sync.RWMutex
	// 放入资源的条件变量。
	pushCond := sync.NewCond(&lock)
	// 获取资源条件变量。
	popCond := sync.NewCond(lock.RLocker())

	push := func(id, index int) {
		lock.Lock()
		for exist == true {
			pushCond.Wait()
		}
		log.Printf("push [%d-%d]: start.", id, index)
		exist = true
		log.Printf("push [%d-%d]: end.", id, index)
		lock.Unlock()
		popCond.Broadcast()
	}

	pop := func(id, index int) {
		lock.RLock()
		for exist == false {
			popCond.Wait()
		}
		log.Printf("pop [%d-%d]: start.", id, index)
		exist = false
		log.Printf("pop[%d-%d]: end.", id, index)
		lock.RUnlock()
		pushCond.Signal() // 确定只会有一个发信的goroutine。
	}

	// sign 用于传递演示完成的信号。
	sign := make(chan struct{}, 3)
	max := 6
	go func(id, max int) {
		defer func() {
			sign <- struct{}{}
		}()
		for i := 1; i <= max; i++ {
			time.Sleep(time.Millisecond * 500)
			push(id, i)
		}
	}(0, max)
	go func(id, max int) {
		defer func() {
			sign <- struct{}{}
		}()
		for j := 1; j <= max; j++ {
			time.Sleep(time.Millisecond * 200)
			pop(id, j)
		}
	}(1, max/2)
	go func(id, max int) {
		defer func() {
			sign <- struct{}{}
		}()
		for k := 1; k <= max; k++ {
			time.Sleep(time.Millisecond * 200)
			pop(id, k)
		}
	}(2, max/2)

	<-sign
	<-sign
	<-sign
}

简单总结下
本文主要分析了条件变量，它是基于互斥锁的一种同步工具。在Go语言中，我们需要用sync.NewCond函数来初始化一个sync.Cond类型的条件变量。sync.NewCond函数需要一个sync.Locker类型的参数值。sync.Mutex类型的值以及sync.RWMutex类型的值都可以满足这个要求。都可以满足这个要求。另外，后者的RLocker方法可以返回这个值中的读锁，也同样可以作为sync.NewCond函数的参数值，如此就可以生成与读写锁中的读锁对应的条件变量了。
条件变量的Wait方法需要在它基于的互斥锁保护下执行，否则就会引发不可恢复的panic。此外，我们最好使用for语句来检查共享资源的状态，并包裹对条件变量的Wait方法的调用。不要用if语句，因为它不能重复地执行”检查状态-等待通知-被唤醒“的这个流程。重复执行这个流程的原因是，一个因等待通知，而被阻塞的goroutine，可能会在共享资源的状态不满足其要求的情况下被唤醒。条件变量的Signal方法只会唤醒一个因等待通知而被阻塞的goroutine，而它的Broadcast方法却可以唤醒所有为此而等待的goroutine。后者比前者的适应场景要多得多。这两个方法并不需要受到互斥锁的保护，我们也最好不要在解锁互斥锁之前调用它们。还有，条件变量的通知具有即时性。当通知被发送的时候，如果没有任何goroutine需要被唤醒，那么该通知就会立即失效。