1：为什么先要锁定条件变量基于的互斥锁，才能调用它的Wait方法？
2：为什么要用for语句来包裹调用其Wait方法的表达式，用if语句不行吗？
这些问题我在面试的时候也经常问。你需要对这个Wait方法的内部机制有所了解才能回答上来。
条件变量的Wait方法主要做了四件事。
- 把调用它的 goroutine（也就是当前的 goroutine）加入到当前条件变量的通知队列中。
- 解锁当前的条件变量基于的那个互斥锁。
- 让当前的 goroutine 处于等待状态，等到通知到来时再决定是否唤醒它。此时，这个 goroutine 就会阻塞在调用这个Wait方法的那行代码上。
- 如果通知到来并且决定唤醒这个 goroutine，那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此之后，当前的 goroutine 就会继续执行后面的代码了。
问题一解答：因为条件变量的Wait方法在阻塞当前的 goroutine 之前，会解锁它基于的互斥锁，所以在调用该Wait方法之前，我们必须先锁定那个互斥锁，否则在调用这个Wait方法时，就会引发一个不可恢复的 panic。为什么条件变量的Wait方法要这么做呢？你可以想象一下，如果Wait方法在互斥锁已经锁定的情况下，阻塞了当前的 goroutine，那么又由谁来解锁呢？别的 goroutine 吗？先不说这违背了互斥锁的重要使用原则，即：成对的锁定和解锁，就算别的 goroutine 可以来解锁，那万一解锁重复了怎么办？由此引发的 panic 可是无法恢复的。如果当前的 goroutine 无法解锁，别的 goroutine 也都不来解锁，那么又由谁来进入临界区，并改变共享资源的状态呢？只要共享资源的状态不变，即使当前的 goroutine 因收到通知而被唤醒，也依然会再次执行这个Wait方法，并再次被阻塞。所以说，如果条件变量的Wait方法不先解锁互斥锁的话，那么就只会造成两种后果：不是当前的程序因 panic 而崩溃，就是相关的 goroutine 全面阻塞。
问题二解答：这主要是为了保险起见。如果一个 goroutine 因收到通知而被唤醒，但却发现共享资源的状态，依然不符合它的要求，那么就应该再次调用条件变量的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）本身提供的条件变量也会如此
来看下signal()代码示列
type User struct { //模拟用户
mail *Mail
}
type Mail struct { //模拟邮箱
mail bool
sendCond *sync.Cond
recvCond *sync.Cond
lock sync.RWMutex
sendName string
recvName string
}
func NewMail() *Mail {
m := Mail{}
m.sendCond = sync.NewCond(&m.lock)
m.recvCond = sync.NewCond(m.lock.RLocker())
return &m
}
func (m *Mail) SendMail() {
m.lock.Lock()
time.Sleep(time.Minute)
if m.mail{
m.sendCond.Wait()
fmt.Println("已经有邮件了等待接收")
}
m.mail = true
fmt.Println("发送了一封邮件给:",m.recvName)
m.lock.Unlock()
m.recvCond.Signal() //向接收者发送消息
}
func (m *Mail) RecvMail() {
m.lock.RLock()
if !m.mail{
fmt.Println("没有邮件，等待邮箱发送邮件")
m.recvCond.Wait()
}
m.mail = false
fmt.Printf("%s收到一封%s发送的邮件\n",m.recvName,m.sendName)
m.lock.RUnlock()
m.sendCond.Signal()
}
func main() {
mail := NewMail()
lock := make(chan struct{},2)
use1 := User{}
use1.mail = mail
use1.mail.sendName = "jacky"
use2 := User{}
use2.mail = mail
use2.mail.recvName = "rose"
//send mail
go func() {
defer func() {
lock <- struct{}{}
}()
for{
use1.mail.SendMail()
time.Sleep(time.Second)
}
}()
go func() {
defer func() {
lock <- struct{}{}
}()
for{
use2.mail.RecvMail()
time.Sleep(time.Second)
}
}()
<-lock
<-lock
}
我们再看下条件变量的Broadcast()通知方法示列
func main() { // mailbox 代表信箱。 // 0代表信箱是空的，1代表信箱是满的。 var mailbox uint8 // lock 代表信箱上的锁。 var lock sync.Mutex // sendCond 代表专用于发信的条件变量。 sendCond := sync.NewCond(&lock) // recvCond 代表专用于收信的条件变量。 recvCond := sync.NewCond(&lock) // send 代表用于发信的函数。 send := func(id, index int) { lock.Lock() for mailbox == 1 { sendCond.Wait() } log.Printf("发送邮件用户%d:准备发送邮件...",index) mailbox = 1 log.Printf("发送邮件用户%d:发送了一份邮件...",index) lock.Unlock() recvCond.Broadcast() } // recv 代表用于收信的函数。 recv := func(id, index int) { lock.Lock() for mailbox == 0 { recvCond.Wait() } log.Printf("用户%d收到邮件:发现有份邮件待接收...",index) mailbox = 0 log.Printf("用户%d收到邮件:收到一份邮件...",index) lock.Unlock() sendCond.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) send(id, i) } }(0, max) go func(id, max int) { // 用于收信。 defer func() { sign <- struct{}{} }() for j := 1; j <= max; j++ { time.Sleep(time.Millisecond * 200) recv(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) recv(id, k) } }(2, max/2) <-sign <-sign <-sign }