关于go channel阻塞的深入讨论

1. 按照通常的理解，Channel满了，就阻塞写；Channel空了，就阻塞读
2. go协程很聪明，阻塞之后它就主动交出cpu，相当于调用runtime.Gosched()，让其他协程去执行，希望其他协程能帮自己解除阻塞（当然是通过读写管道的方式）
3. 如果阻塞发生在main协程里，并且没有其他子协程可以执行，那就可以确定“希望永远等不来”，自已把自己杀掉，报一个fatal error:deadlock出来
4. 如果阻塞发生在子协程里，就不会发生死锁，因为至少main协程是一个值得等待的“希望”，会一直等下去

结论：读一个空管道或写一个缓冲已经满的管道，到底会发生什么行为，需要分情况讨论：

1. 发生在非main协程里，则阻塞
2. 发生在main协程里
　　2.1 没有其他非main协程可以执行，报 fatal error: all goroutines are asleep - deadlock!
　　2.2 有其他非main协程可以执行，则main协程会让他们先执行
　　　　2.2.1 非main协在程执行过程中，帮main协程解除了阻塞
　　　　2.2.2 非main协执行结束后，依然没有帮main协程解除阻塞，则main协程报 fatal error: all goroutines are asleep - deadlock!

最后附上测试代码：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

package main   import (     "time" )   func main() {     ch := make(chan struct{}, 1)     ch <- struct{}{} //有1个缓冲可以用，无需阻塞，可以立即执行     go func() {      //子协程1         time.Sleep(5 * time.Second) //sleep一个很长的时间         <-ch     }()       ch <- struct{}{} //由于子协程1已经启动，寄希望于子协程1帮自己解除阻塞，所以会一直等子协程1执行结束。如果子协程1执行结束后没帮自己解除阻塞，则希望完全破灭，报出deadlock     go func() {      //子协程2         time.Sleep(5 * time.Second)         <-ch     }() }