> ### 条件锁 ~~~ package main import ( "sync" "fmt" "time" ) func main() { cond := sync.NewCond(&sync.Mutex{}) for i := 0; i < 10; i++ { go func(n int) { cond.L.Lock() cond.Wait() fmt.Println(n) cond.L.Unlock() }(i) } time.Sleep(time.Second) //唤醒G(一般是唤醒最早等待的G) cond.Signal() //唤醒所有等待的G //cond.Broadcast() time.Sleep(time.Second * 2) } ~~~ > ### 其它例子 * 条件锁 ~~~ package main import ( "sync" "fmt" "time" ) var mailbox uint var lock sync.RWMutex func main() { sendCond := sync.NewCond(&lock) reciverCond := sync.NewCond(lock.RLocker()) //接收方 go func(){ //因为条件变量的方法在阻塞当前的 goroutine 之前，会解锁它基于的互斥锁，所以在调用该方法之前，我们必须先锁定那个互斥锁，否则在调用这个方法时，就会引发一个不可恢复的 panic。 lock.RLock() //这主要是为了保险起见。如果一个 goroutine 因收到通知而被唤醒，但却发现共享资源的状态，依然不符合它的要求，那么就应该再次调用条件变量的Wait方法，并继续等待下次通知的到来。 //在一些多 CPU 核心的计算机系统中，即使没有收到条件变量的通知，调用其Wait方法的 goroutine 也是有可能被唤醒 for mailbox == 0 { //把调用它的 goroutine（也就是当前的 goroutine）加入到当前条件变量的通知队列中。 //解锁当前的条件变量基于的那个互斥锁。 //让当前的 goroutine 处于等待状态，等到通知到来时再决定是否唤醒它。此时，这个 goroutine 就会阻塞在调用这个 //如果通知到来并且决定唤醒这个 goroutine，那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此之后，当前的 goroutine 就会继续执行后面的代码了。 reciverCond.Wait() } mailbox = 0 //如果当前的 goroutine 无法解锁，别的 goroutine 也都不来解锁，那么又由谁来进入临界区，并改变共享资源的状态呢？只要共享资源的状态不变，即使当前的 goroutine 因收到通知而被唤醒，也依然会再次执行这个Wait方法，并再次被阻塞。 lock.RUnlock() //条件变量的Signal方法(唤醒的 goroutine 一般都是最早等待的那一个)和Broadcast都是被用来发送通知的，不同的是，前者的通知只会唤醒一个因此而等待的 goroutine，而后者的通知却会唤醒所有为此等待的 goroutine。 //Broadcast //(1)多个读操作可以同时进行。因此被唤醒时如果都是获取读锁的请求，他们都是可以成功返回的。 //(2)但如果是WLock()写锁的情况，就会有等待最久的那个能完成获取锁的需求。 //最后，请注意，条件变量的通知具有即时性。也就是说，如果发送通知的时候没有 goroutine 为此等待，那么该通知就会被直接丢弃。在这之后才开始等待的 goroutine 只可能被后面的通知唤醒。 sendCond.Signal() fmt.Println(2) }() //发送方 go func() { time.Sleep(time.Second) lock.Lock() for mailbox == 1 { sendCond.Wait() } mailbox = 1 lock.Unlock() reciverCond.Signal() fmt.Println(1) }() time.Sleep(time.Second * 10) } ~~~