深入理解 Go 语言并发编程--管道（channel) 的底层原理

Mindfulness code

已于 2024-08-23 21:24:44 修改

阅读量461

点赞数 16

分类专栏： Go语言开发文章标签：开发语言后端 Go channel

于 2024-08-23 21:24:21 首次发布

本文链接：https://blog.csdn.net/canglonghacker/article/details/141461889

版权

Go语言开发专栏收录该内容

114 篇文章 1 订阅

订阅专栏

管道是 Go 语言协程间通信的一种常用手段，管道的读写操作也有可能会阻塞用户协程，也就是说有可能会切换到调度器。协程因为管道而阻塞时，只有当其他协程再次读或者写管道时，才有可能解除这个协程的阻塞状态。

1. 管道的基本用法

管道是 Go 语言协程间通信的一种常用手段，可以分为无缓冲管道和有缓冲管道。因为无缓冲管道本身没有容量，不能缓存数据，所以只有当协程在等待读时，写操作才不会阻塞协程；或者当有协程在等待写时，读操作才不会阻塞协程。因为有缓冲管道本身有一定容量，可以缓存一定数据，所以当协跑第一执行写操作时，即使没有其他协程在等待读，只要管道还有剩余容量，写操作就不会阻塞协程；或者当协程执行读操作时，即使没有其他协程在等待写，只要管道还有剩余数据，读操作就不会阻塞协程。

下面写一个简单的 Go 程序，学习管道的基本用法，代码如下所示：

package main

import (
	"fmt"
	"time"
)

func main() {
	queue := make(chan int, 1)
	go func() {
		for {
			data := <-queue     //读取
			fmt.Print(data, "") //0 1 2 3 4 5 6 7 8 9
		}
	}()

	for i := 0; i < 10; i++ {
		queue <- i //写入
	}
	time.Sleep(time.Second)
}

参考上面代码，主协程循环向管道写入整数，子协程循环从管道读取数据。主协程休眠 1s 是为了防止主协程结束，整个 Go 程序退出，导致子协程也提前结束。函数 make 用于初始化 Go 语言的一些内置类型，如切片 slice、散列列 map 以及管道 chan。注意用函数 make 初始化时，第一个参数 chan int 表示管道只能用来传递整型数据，第二个参数表示管道的容量是 1,即最多只能缓存一个整型数据。

管道的操作还是比较简单的，无非就是读、写以及关闭操作。这里提出一个问题，如果程序没有初始化管道，却执行读或者写操作会发生什么呢？或者说，如果一个管道已经被关闭了，这时候执行读或者写操作会发生什么呢？我们写一些简单的 Go 程序测试一下。

第 1 个程序：不初始化管道，直接执行写操作，代码与运行结果如下所示：

package main

import (
	"fmt"
)

func main() {
	var queue chan int
	queue <- 100
	fmt.Println("main end")
}

运行上面的程序，竟然报错了，提示 all goroutines are asleep,意思是所有的协程都在休眠，程序死锁了。为什么所有的协程都在休眠呢？其实是由主协程向未初始化的管道写数据导致的，也就是说，向未初始化的管道写数据会导致协程永久性阻塞。

第 2 个程序：不初始化管道，直接执行读操作，代码与运行结果如下所示：

package main

import (
	"fmt"
)

func main() {
	var queue chan int
	data := <-queue
	fmt.Println("main end",data)
}

可以看到，第 2 个程序的运行结果与第 1 个程序一致，主协程同样被阻塞了，即从未初始化的管道读数据也会导致协程的永久性阻塞。

第 3 个程序：关闭管道之后，再执行写操作，代码与运行结果如下所示：

package main

import (
	"fmt"
)

func main() {
	queue := make(chan int, 1)
	close(queue)

	queue <- 100
	fmt.Println("main end")
}

第 4 个程序：关闭管道之后，再执行读操作，代码与运行结果如下所示：

package main

import (
	"fmt"
)

func main() {
	queue := make(chan int, 1)
	queue <- 100
	close(queue)

	data1 := <-queue
	fmt.Println("main end1", data1)

	data2 := <-queue
	fmt.Println("main end2", data2)
}

我们先向管道写入一个整型数据 100,再关闭管道，随后从管道读取两次数据。参考上面的输出结果，程序输出了两条语句，第一次正常读取到了数据 100，第二次读取到的是 0。通过这个例子可以说明，即使管道关闭之后，也可以正常地从管道读取数据，没有数据时直接返回对应的空值（整型空值是 0，字符串空值是空字符串等）。

最后一个问题，如果关闭未初始化的管道，会怎么样呢？或者说再次关闭已关闭的管道，会怎么样呢？参考上面 4 个程序，你也可以写两个简单的程序测试一下，这里我就直接给出答案了：如果管道未初始化，关闭管道会导致程序抛 panic 异常（异常提示信息为 close of nil channel); 如果管道已经被关闭，再次关闭管道也会导致程序抛 panic 异常（异常提示信息为 close of closed channel)。

2. 管道与调度器

管道的读写操作有可能会阻塞用户协程，并切换到调度器；而协程因管道而阻塞时，只有当其他协程再次读或写管道时，才有可能解除这个协程的阻塞状态。在介绍管道与调度器之间的联系之前，先思考一下：Go 语言如何维护因读写管道而阻塞的协程呢？有没有专门的阻塞协程队列呢？

回顾一下网络 I/O 与调度器，因为读写套接字阻塞的协程，只有当 Go 语言检测到套接字可读、可写时，才能解除这个协程的阻塞状态。代表套接字的结构体 runtime.pollDesc 就保存了因读套接字以及写套接字而阻塞的协程，不然即使 Go 语言检测到套接字可读 / 可写，又怎么关联到对应的协程呢？

按照这个思路，我们是不是可以猜测，因读写管道而阻塞的协程是不是就维护在管道本身呢？不然，当其他协程再次读或写管道时，该如何去获取这些阻塞的协程呢？

是不是这样呢？我们可以看一下管道的结构定义，代码如下所示：

type hchan struct {
	// 当前管道存储的元素数目
	qcount uint
	//管道容量
	dataqsiz uint
	//数组
	buf unsafe.Pointer
	//标识管道是否被关闭
	closed uint32
	//管道存储的元素类型与元素大小
	elemtype *_type
	elemsize uint16
	//读/写 索引，循环队列
	sendx	uint
	recvx	uint
	//读阻塞协程队列，写阻塞协程队列
	recvq 	waitq
	sendq	waitq
	// 锁
	lock mutex
}

管道的结构定义可以参考文件 runtime/chan.go 各字段含义如下。

1）qcount: 整数类型，表示管道已经存储的数据量。当 qcount 等于 0 时，说明管道没有数据可读，此时读管道会阻塞用户协程。

2）dataqsiz: 整数类型，表示管道的容量。当 qcount 等于 dataqsiz 时，说明管道已经没有剩余容量了，此时写管道会阻塞用户协程。

3）buf: 指针类型，指向一个数组，用于存储缓存在管道的数据，数组的容量等于 elemsize 乘以 dataqsiz 。

4）sendx/recvx: 管道本身维护了一个循环数据 buf, sendx 指向写索引位置，recvx 指向读索引位置。

5）lock: 用于锁定管道。管道用于多协程通信，通常是一个协程读管道，另外一个协程写管道，多个协程并发操作同一个数据时需要加锁。

文件 runtime/chan.go 不仅定义了管道的数据类型，还包括了所有管道操作的实现函数，如初始化管道、读管道、写管道、关闭管道等实现函数。各函数定义如下：

// 初始化管道：size 就是 chan 容量
func makechan(t *chantype,size int) *hchan
//读管道：读取到的数据就存储在 ep 指针；block 表示如果管道不可读，是否阻塞协程
func chanrecv(c *hchan,ep unsafe.Pointer,block bool)
//写管道:待写入的数据就存储在 ep 指针；block 表示如果管道不可写，是否阻塞协程
func chansend(c *hchan,ep unsafe.Pointer,block bool,callerpc uintptr
//关闭管道
func closechan(c *hchan)

我们以写管道的实现函数为例，学习写管道是如何阻塞用户协程的，又是如何切换到调度器的，以及是如何解除其他因读管道而阻塞的协程的，代码如下所示：

func chansend(c *hchan,ep unsafe.Pointer,block bool,callerpc uintptr) bool {
	//如果未初始化；如果 block 为 false,函数立即返回，否则永久阻塞协程
	if c == nil {
		if !block {
			return false
		}
		//切换到调度器
		gopark(nil,nil,waitReasonChanSendNilChan,traceEvGoStop,2)
	}
	//加锁
	lock(&c.lock)
	//如果已关闭，抛出 panic 异常
	if c.closed !=0 {
		unlock(&c.lock)
		panic(plainError("send on closed channel"))
	}
	//如果读协程队列不为空，则获取阻塞协程并解除该协程阻塞状态
	if sg := c.recvg.dequeue();sg != nil {
		send(c,sg,ep,func(){ unlock(&c.lock)},3)
		return true
	}
	//如果管道还有剩余容量，写数据
	if c.qcount < c.dataqsiz{
		.....
	}
	//如果 block 为 false,函数立即返回
	if !block {
		unlock(&c.lock)
		return false
	}
	// 添加到阻塞协程队列
	mysg := acquireSudog()
	mysg.elem = ep
	mysg.g = gp
	c.sendq.enqueue(mysg)
	//切换到调度器
	gopark(chanparkcommit,unsafe.Pointer(&c.lock),waitReasonChanSend,traceEvGo-Blocksend,2)
	......
	return true
}

参考上面的代码，函数 chansend 的主要流程如下：

第 1 步：如果管道未初始化，普通的写管道操作（这种情况下 block 等于 true) 会导致协程的永久性阻塞。

第 2 步：如果管道已经被关闭，写管道会导致程序抛出 panic 异常。

第 3 步：如果检测到读阻塞协程队列为空，则获取队首阻塞协程，并解除该协程的阻塞状态，这一操作同样基于 runtime.goready 函数实现，当然这里也只是将协程添加到了可运行协程队列等待调度器的调度执行，至此写管道操作就算完成了。

第 4 步：如果管道还有剩余容量，则将数据复制到循环队列后返回，注意需要更新管道数据 qcount 以及写索引位置 sendx。

第 5 步：如果 block 等于 false,返回 false,表示写管道失败。

第 6 步：执行到这里，说明需要阻塞当前协程，首先将其添加写阻塞协程队列，随后通过函数 runtime.gopark 切换到调度器，重新调度执行其他协程。