关于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!

最后附上测试代码：

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
	}()
}