golang并发编程-channel

channel

channel类型的值本身就是并发安全的，这也是Go语言自带的、唯⼀⼀个可以满足并发安全性的类型。一个channel就是一个先进先出的队列。

创建方式：

ch := make(chan int, 10)

后面的数字代表缓冲队列的容量，如果容量为0则代表不适用缓冲队列

如果我们仅定义通道 ，而不用make进行初始化，该通道的值就为nil，对于一个值为nil的通道，对它的任何接收和发送操作，都会被一直阻塞。

阻塞问题：

缓冲通道

元素发送到channel，会按照发送顺序依次排入缓冲队列，如果缓冲队列已满，则对该通道的所有发送操作都会被阻塞，并且发送操作所在的goroutine会顺序地进入通道内部的等待队列，直到通道中有元素被取走，等待队列头部的goroutine才会继续执行发送操作。

同理，当缓冲队列为空的时候，如果还要从channel里接收元素，那么该接收操作也会被阻塞，所在的goroutine同样会放入等待队列。

非缓冲通道

在非缓冲通道中，元素的发送方和接收方对接上，该元素才会被传递。无论发送操作还是接收操作，开始执行的时候就被阻塞，直到配对的操作开始执行。

要传递的元素在大部分情况下，会先从发送方复制 到缓冲通道，之后再由缓冲通道复制给接收方，并删除在通道中该元素的副本。不过，当发送操作在执行时，通道为空，而且刚好存在配对的接收操作，发送方会直接将该元素的副本传递给接收方。

panic

对于一个已关闭的channel，如果我们继续给它发送元素，或者我们尝试关闭一个已经关闭的channel，会引发panic。

接收表达式：x, ok <- ch1 。

其中ok为bool类型，当ok为false的时候，代表channel已关闭，并且无元素可取。但是当ok为true的时候，channel也可能是关闭的，这种情况下，在channel中有还未被取出的元素。

所以，我们需要在发送方来进行关闭channel的操作，在接收方来关闭会存在引发panic的风险。