一、条件变量与互斥锁
- 条件变量是基于互斥锁的，它必须基于互斥锁才能发挥作用；
- 条件变量并不是用来保护临界区和共享资源的，它是用来协调想要访问共享资源的那些线程的；
- 在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语句，因为它不能重复地执行“检查状态 - 等待通知 - 被唤醒”的这个流程。
（4）条件变量的Signal方法和Broadcast方法
条件变量signal方法和Broadcast方法都是用来发送通知的，不同的是，前者的通知只会唤醒一个因此而等待的goroutine，而后者的通知却会唤醒所有为此等待的goroutine。
条件变量的Wait方法总会把当前的 goroutine 添加到通知队列的队尾，而它的Signal方法总会从通知队列的队首开始，查找可被唤醒的 goroutine。所以，因Signal方法的通知，而被唤醒的 goroutine 一般都是最早等待的那一个。
条件变量Signal方法和Broadcast方法放置的位置：
与Wait方法不同，条件变量的Signal方法和Broadcast方法并不需要在互斥锁的保护下执行。恰恰相反，我们最好在解锁条件变量基于的那个互斥锁之后，再去调用它的这两个方法。这更有利于程序的运行效率。
条件变量的通知具有即时性：
如果发送通知的时候没有 goroutine 为此等待，那么该通知就会被直接丢弃。在这之后才开始等待的 goroutine 只可能被后面的通知唤醒。
到此这篇关于GoLang并发编程中条件变量sync.Cond的使用的文章就介绍到这了,更多相关Go sync.Cond内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！