GO中的Channel以及死锁的造成

写在前面

这篇文章的诞生要感谢MIT 6.284课程。在其中一节课中，谈到了多线程的协同的一些问题，其中就涉及到了channel这个概念，并由一段代码引发思考并逐渐深入得到了这篇文章。

引子

课程中有一段代码如下：

其大致含义是：代码背景是在进行多线程网络爬虫页面url，master线程启动后，从channel通道中读取当前页面的所有url即urls，接着再对这个urls中的每一个url进行爬虫读取新页面中的urls（即执行go worker(u, ch ,fetcher)），每启动一个worker线程便开始向channel中写入该url指向页面中所有包含的urls，以供master线程读取。

问题抛出

那么问题来了，为什么第一层for循环不会range完ch之后便直接结束循环，还需要利用局部变量n来根据特定情况跳出循环？

问题解释

课程上的解释是，这个range会一直阻塞，但并未提出解释。其实，这里很容易分析，因为当前的channel是一个无缓冲通道。所谓无缓冲通道，简单的讲就是两个线程对channel进行操作，一个读，一个写，永远都只能是写一个，读一个按照这样的顺序进行。更详细一些的话，读的那个线程会一直阻塞，直到写的线程向channel中写入一个数据。反之亦然，写的线程在完成一次写操作之后，也会一直阻塞直到另外一个线程完成对该channel的读取操作。上述情况只有一种例外状况，那就是该channel通道被某个线程close掉了：close(channel)。
而这里的range其实不太等同于对数组的range，这里的range实质上为对channel通道的读取。所以，在并未有认为close通道的前提下，该for循环会一直阻塞，不会退出，于是需要设定一个局部状态量n让其退出循环，保证程序的正常运行。当然我们也可以通过close其channel来实现，不过我认为close的时机可能不是非常容易把握。

继续深入

完成上述思考之后，对channel进行了较为的深入的分析，当然分析是以具体的实验展开的。给出下述实验代码：

func main() {
   
    test()
}

func test()  {
   
	ch