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

上一篇:linux – Mercurial和Hudson在网络托管上.我可以安装Mercurial吗?


下一篇:解决“该Jenkins实例似乎已离线”