从 Go channel 源码中理解发送方和接收方是如何相互阻塞等待的

date

Dec 14, 2023

slug

golang-channel-source-code-sender-receiver-block

status

Published

并发编程的可见性

在 Go 官网上的内存模型一文中，介绍了在 Go 并发编程下数据可见性问题，可见性是并发编程中一个重要概念，指的是在哪些条件下，可以保证一个线程中读取某个变量时，可以观察到另一个线程对该变量的写入后的值，Go 语言中的 goroutine 也适用。

一般来说可见性属于偏硬件和底层，因为涉及到多核 CPU 的 cache 读写和同步问题，开发者不需要关心细节，高级编程语言要么屏蔽掉了这些细节，要么会给出一些保证，承诺在确定的条件下就会得到确定的结果。

Go channel 有一个特性是在一个无缓冲的 channel 上发送和接收必须等待对方准备好，才可以执行，否则会被阻塞。实际上这就是一个同步保证，那么这个同步保证是如何实现的？下面看看官方文章中是如何解释的。

先 send 后 receive

文中对 channel 的描述有几个原则，第一个是

A send on a channel is synchronized before the completion of the corresponding receive from that channel.

意思是：在一个 channel 上的发送操作应该发生在对应的接收操作完成之前。说人话就是：要先发送数据，然后才能接收数据，否则就会阻塞。这也比较符合一般的认知。

并用下面一段代码举例说明，这段代码确保一定会输出 "hello, world”。

f 函数负责给变量 a 赋值，main 函数负责打印变量 a。main 函数阻塞等待在 <- c 处，直到 f 函数对 a 赋值之后并写入数据到 c 中，main 函数才被唤醒继续执行，所以此时打印 a 必然会得到结果。

先 receive 后 send？

而下面这段描述有点反直觉

A receive from an unbuffered channel is synchronized before the completion of the corresponding send on that channel.

意思是在无缓冲 channel 上的接收操作发生在对应的发送操作完成之前，说人话就是：要先接收数据，之后才可以发送数据，否则就会阻塞。这句话看上去与第一条相悖，因为第一条强调发送操作要在接收完成之前发生，而这一条强调接收操作要在发送完成之前发生，这样相互等待对方的情况，不会陷入死锁状态吗？

下面的示例代码与前一个类似，区别是将 c 换成了无缓冲 channel，并把 c 的写入和读取调换了位置，这段代码同样可以保证输出 "hello, world”。

这两段话到底是什么意思？为什么要相互等待但又不会死锁？

接下来看看 runtime/chan.go 中是怎么实现 channel 的发送和接收的。

channel 的结构

首先看看 channel 的数据结构

channel 内部实现了一个环形队列，通过 qcount dataqsiz buf sendx recvx 几个部分组成。

另外 channel 还维护了两个等待队列，如果在执行 <-c receive 操作时，此时 channel 不满足接收条件，receiver 会进入 recvq 等待队列；同样的如果执行 c<- send 操作时，此时 channel 不满足发送条件，sender 会进入 sendq 等待队列。

具体看代码：

send 具体干了什么

当 main 函数执行到 c<-123456 是，会执行 runtime/chan.go 中的 chansend 函数，该函数首先会判断当前 channel c 的等待接收队列是否有阻塞的 receiver

如果有等待的 receiver 则弹出队列，调用 send 函数，其中 sg 就表示 receiver，sg.elem 表示将数据接收到哪里去，这个地址也就对应示例代码中的变量 x 的地址。

sendDirect 函数就是直接从 src 里面将数据复制到 dst 中。

回到 chansend 函数，如果没有等待的 receiver，那么会查看当前 buf 中是否有空间，如果有空间，则数据缓存到 buf 中。

如果也没有 buf 空间，那么就将 sender 本身放入到 sendq 等待队列中。

总结起来 send 操作分三部分：

如果当前 channel 上有等待的 receiver，则直接 copy 数据过去

否则如果当前 buf 有空闲空间，则将数据存在 buf 中

否则将 sender 本身加入到 sendq 等待队列中

receive 具体干了什么

相应的与发送类似，执行到示例代码中第 (3) 步接收数据时，会调用 runtime/chan.go 中的 chanrecv 函数来处理接收，同样是先看 sender 等待队列是否有阻塞的 sender

如果有等待的 sender，那么将 sender 取出来，并复制数据。

如果没有等待的 sender，那么看 buf 中有没有缓存的数据

最后如果也没有 buf 数据，那么久把自己加入到 receiver 等待队列中 recvq

总结起来 receive 操作分三部分：

如果当前 channel 上有等待的 sender，则直接 copy 数据过去

否则如果当前 buf 有缓存的数据，则将读取该数据

否则将 receiver 本身加入到 recvq 等待队列中

小结

这样一来就能够理解前面的两个原则了，在一个无缓冲的 channel 中，无论是 sender 先执行，还是 receiver 先执行，都会因为找不到对方，并且没有 buf 空间的情况下，将自己加入到等待队列；当对方开始执行时就会检查到已经有对端正在阻塞，进而拷贝数据，并唤醒阻塞的对象最终走完整个流程。

有一种说法是：sender 必须在 receiver 准备好才能执行，否则就会阻塞；而 receiver 必须在 sender 准备好才能执行，否则就会阻塞；这个说法没错，但是太笼统了，什么叫准备好？怎么算是准备好？这是比较模糊的。而看过 send 和 receive 的流程之后，就更能理解整个过程了。

为什么要有无缓冲 channel

实际上两个 goroutine 相互等待对方到达某个状态的效果，非常类似操作系统中的一种同步机制：屏障 barrier，同步屏障要求只有当所有进程都到达屏障后，才能一起执行下一状态，否则就阻塞在屏障处。

回到 channel 操作，即 sender 和 receiver 无论谁先执行，都必须等待对方也已经执行，两者才可以继续执行。就像一块电路板串联有两个开关，要想电路联通，必须两个开关都被打开才可以，而不管哪一个先打开，都必须等待另一个开关也打开，之后电流才可以接通电路也才联通。

可以将无缓冲 channel 看做是一种同步屏障，同步屏障能够让多个 goroutine 都达到某种状态之后才可以继续执行，这是带缓冲 channel 无法做到的。另外在无缓冲 channel 数据的交换更加简单快速，因为不需要维护缓存 buf，实现逻辑也更简单，运行更可靠。