深入理解 go chan
go
里面,在实际程序运行的过程中,往往会有很多协程在执行,通过启动多个协程的方式,我们可以更高效地利用系统资源。
而不同协程之间往往需要进行通信,不同于以往多线程程序的那种通信方式,在
go 里面是通过 channel (也就是 chan
类型)来进行通信的, 实现的方式简单来说就是,一个协程往
channel 里面写数据,然后其他的协程可以从
channel 中将其读取出来。 (注意:文中的 chan
表示是 go 语言里面的 chan 关键字,而 channel
只是我们描述它的时候用的一个术语)
通道(chan)的模型
在开始讲 channel
之前,也许了解一下它要解决什么样的问题会比较好,所以先来聊聊一些背景知识。
关于通道,一个比较潦草的图大概是下面这个样子的:

在图中,协程 A 将消息 msg 写入到
channel 中,然后协程 B 从 channel
中读取消息,如果 B 没来得及从中读取消息,那么消息会在
chan 中存留。
这就是 go
的哲学:通过通信来实现共享内存。这不同于以往的多线程程序,在多线程程序中,往往是一块内存在不同线程之间进行共享,
然后通过一些保护机制,保证不允许多个线程同时对这块内存进行读写,比如通过
synchronized 关键字。
可能很多人都没有真正写过多线程的程序,但好像我们都有一种共识,多线程不安全。
多线程为什么不安全?
这是因为我们的程序除了通过共享一段内存之外,每一个 CPU 核心都有它本地的缓存,而 CPU 上的缓存是不共享的, 而线程可以同时在不同的 CPU 上执行。CPU 的执行过程是,先从内存中读取数据到 CPU 中,CPU 做完计算再更新到内存中。 这样一来,就有可能存在不同线程对同一段内存同时读写的问题。
这是什么问题呢?比如,A
线程计算完了但是还没有写回内存的时候,B 线程从内存读取出了
A 线程写入计算结果前的数据,
但是按我们的逻辑,B 应该是拿 A
线程的结算结果来进行逻辑运算的,这样就会出现数据不一致了,代码如下:
1 | public class Main { |
在上面的代码中,我们预期的运行结果是 20000
的,但是实际得到了
14965(实际上,每次执行结果都会不一样),这也就是我上面所说的问题,
其中有一个线程读取到了另一个线程的计算结果写入内存前的数据,也就是说,这个线程的计算结果被覆盖了,
因为线程将计算结果写回内存的时候是相互覆盖的。
所以我们可以回答刚才的问题了,多线程不安全是因为多个线程可以对同一段内存进行读写,这就存在其中一个线程还没来得及更新内存, 然后另一个线程读取到的数据是旧的。(也即数据竞争的问题)
具体可以看下图:

CPU 执行的时候,会需要将数据从内存读取到 CPU 中,计算完毕之后,再更新内存里面的数据。
错乱发生的过程大概如下:
CPU 1先计算完了,计算的结果是a = 3,但是还没来得及写入内存CPU 2也从内存里面获取a来进行计算,但是这个时候a还没有被CPU 1更新,所以CPU 2拿到的还是 2CPU 2进行计算的时候,CPU 1将它的计算结果写入了内存,所以这个时候内存中的a是 3CPU 2计算完毕,将等于 2 的变量a加 1 得到结果 3CPU 2将结果 3 写入到内存,这个时候a的内存被更新,但是结果依然是 3
一种可行的办法 - 锁
其中一种可行的办法就是,给 add 方法加上
synchronized 关键字:
1 | private synchronized void add() { |
这个时候,在我们的代码中,对 a 读写的代码都被
synchronized
保护起来了,在这段更新之后的代码中,我们得到了正确的结果
20000。
a++其实包含了读和写两个操作,程序运行的时候,会先将 a 读取出来,将其加上 1,然后写回到内存中。
synchronized
是同步锁,它修饰的方法不允许多个线程同时执行。synchronized
锁的粒度可大可小,粒度太大的话对性能影响也较大。
正如我们所看到的那样,
synchronized允许修饰一段代码,但是在实际中我们往往只是想保护其中某一个变量而已, 如果直接使用synchronized关键字来修饰一大段代码,那就意味着一个线程在执行这段代码的时候,其他线程就只能等待, 但是实际上,其中那些不涉及数据竞争的代码我们也无法执行,这样效率自然会降低,具体降低多少,取决于我们synchronized块的代码有多大。
go 中的处理办法
上面我们说到的多线程是通过共享内存来进行通信的,而在 go 里面,采用了
CSP(communicating sequential processes)并发模型, CSP
模型用于描述两个独立的并发实体通过共享
channel(管道)进行通信的并发模型。
CSP 是一套很复杂的东西,go 语言并没有完全实现它,仅仅是实现了
process 和 channel
这两个概念。process 就是 go 语言 中的
goroutine,每个 goroutine 之间是通过
channel 通讯来实现数据共享的。
然后我们上面说到,java 里面的 synchronized
关键字的粒度可能会比较大,这个是相比 go 里面的 channel
而言的, 在 go 里面,我们的代码在通信过程中很常见的一种阻塞场景是:
goroutine需要从channel读取数据才能继续执行,但是channel里面还没数据,这个时候goroutine需要等待(会阻塞)另一个goroutine往channel写入数据。
对于这种场景,它隐含的逻辑是,阻塞的这个 goroutine
需要等待其他 goroutine 的结果才能继续往下执行,也就是 CSP
中的 sequential。下图是实际运行中的 chan:

我们上面的 chan
模型那个图,读和写都只有一个协程,但在实际中,读 chan 和写
chan 的协程都有一个队列来保存。
我们需要明确的一点事实是:队列中的协程会一个接一个执行,队列头的协程先执行,然后我们对
chan 的读写是按顺序来读写的,先取 chan
队列头的元素,然后下一个元素。
对应到上面 java 这个例子,我们在 go 里面可以怎么做呢?我们先把没有锁的 java 代码先写成 go 的代码:
1 | package main |
在 go 里面,我们可以把 add 方法改成下面这个样子:
1 | func add(ch chan int, done chan<- struct{}) { |
这种写法看起来很笨拙,我们在实际使用中可能会稍有不同,所以不需要太纠结这个例子的合理性,这里想表达的是:在
go 中,我们的协程使用 chan 的时候只会阻塞在
chan
读写的地方,其他代码不受影响,当然,这个例子也没能很好体现。
假设我们有很大一段代码,但是涉及到数据竞争的时候,协程只会阻塞在
chan读写的那一行代码上。这样一来我们就不用通过锁来覆盖一大段代码。
这里,我们可以看到 chan
其中一个很明显的优势是,我们没有了 synchronized
那种大粒度的锁,我们的 goroutine 只会阻塞在某一个
channel 上, 在读取 channel
之前的代码,goroutine
都是可以执行的,这样就在语言层面帮我们解决了一个很大的问题,
因为粒度更小,我们的代码自然也就能处理更大的并发请求了。
进程的几种状态
在开始讲述 channel
之前,再来回忆一下进程的几种状态会便于我们理解。
我们知道,我们的电脑上,同一时刻会有很多进程一直在运行,但是我们也发现很多进程的
CPU 占用其实都是 0%,也就是不占用 CPU。
其实进程会有几种状态,进程不是一直在运行的,一般来说,会有
执行、阻塞、就绪
几种状态,进程不是运行态的时候,那它就不会占用你的 CPU,因此会看到 CPU
占用是 0%,它们之间的转换如下图:

执行:这表示进程正在运行中,是正在使用 CPU 的进程。在就绪状态的进程会在得到CPU时间片的时候得以执行。阻塞:这表示进程因为某些需要的资源得不到满足而挂起了(比如,正在进行磁盘读写),这种状态下,是不用占用CPU资源的。就绪:这表示一个状态所需要的资源都准备好了,可以继续执行了。
进程的几种状态跟 channel 有什么关系?
在 go 里面,其实协程也存在类似的调度机制,在协程需要的资源得不到满足的时候,也会被阻塞,然后协程调度器会去执行其他可以执行的协程。
比如下面这个例子:
1 | func main() { |
在这个例子中 done <- struct{}{} 这一行往
done 这个 chan 写入了数据,之前一直在等待
chan 的 main
协程的阻塞状态解除,得以继续执行。
goroutine 在等待 chan 返回数据的时候,会陷入阻塞状态。一个因为读取 chan 陷入阻塞状态的 goroutine 在获取到数据的时候,会继续往后执行。
channel 是什么?
我们在文章开头的第一张图,其实不是很准确。在 go
里面,channel
实际上是一个队列(准确来说是环形队列),大概长得像下面这样:

队列我们都知道,我们可以从队列头读取数据,也可以将数据推入到队列尾。上图中,1
是队列头,当我们从 channel 读取数据的时候, 读取到的是
1,6 是队列尾,当我们往 channel
中写入数据的时候,写入的位置是 6 后面的那个空间。
channel是一个环形队列,goroutine 通过 channel 通信的方式是,一个 goroutine 将数据写入队列尾,然后另一个 goroutine 将数据从队列头读数据。
如何使用 channel
我们再仔细看看上面的例子:
1 | package main |
这里面包含了使用 channel 的基本用法:
done := make(chan struct{}):创建channel,在 go 里面是使用chan关键字来代表一个channel的。而在这个语句中,创建了一个接收struct{}类型数据的chan。done <- struct{}{}:写入到chan,这里,我们创建了一个空结构体,然后通过<-操作符将这个空结构体写入到了chan中。<-done:从chan中读取数据,也是使用了<-操作符,然后我们丢弃了它的返回结果。
这段代码的执行过程如下图:

CPU 1上启动了main协程- 接着在
main协程中通过go func启动了一个新的协程,go 的调度机制允许不同的协程在不同的线程上执行,所以main执行的时候,go func也在执行,然后,因为done这个chan中没有数据,所以main协程陷入阻塞。 go func在短暂的睡眠之后,输出了done,然后向名字为done这个chan中发送了一个空结构体实例。- 在
done里面没有写入数据之前,main一直阻塞,在go func写入数据之后,main的<-done,解除了阻塞状态,得以继续执行 5和6因为可能是在不同的线程上执行的,所以哪一个先结束其实不一定。
下面详细说说 channel 的具体用法
创建 chan
chan是 go 的关键字,channel是我用来描述chan所表示的东西的一个术语而已,我们在 go 里面使用的话还是得用chan关键字。
创建 chan 是通过 make 关键字创建的:
1 | ch := make(chan int) |
make 函数的参数是 chan
然后加一个数据类型,这个数据类型是我们的 chan
这个环形队列里面所能存储的数据类型。 不能传递不同的类型进一个
chan 里面。
也可以传递第二个参数作为 chan 的容量,比如:
1 | ch := make(chan int, 3) |
这里第二个参数表明了 ch 这个 chan
到底能存储多少个 int 类型的数据。
不传递或者传 0 表示
chan本身不能存储数据,go 底层会直接在两个 goroutine 之间传递,而不经过chan的复制。 (如果第二个参数大于 0,我们往chan写数据的时候,会先复制到chan这个数据结构,然后其他的goroutine从chan中读取数据的时候,chan会将数据复制到这个goroutine中)
chan 读写的几种操作
- 写:
ch <- x,将x发送到 channel 中 - 读:
x = <-ch,从channel中接收,保存到x中 - 读,但是忽略返回值(用作协程同步,上面的例子就是):
<-ch,从ch中接收,但是忽略接收到的结果 - 读,并且判断是否是关闭前发送的:
x, ok := <-ch,这里使用了两个返回值接收,第二个返回值表明了接收到的x是不是chan关闭之前发送进去的,true就代表是。
需要注意的是 <-ch 和 ch<-
这两个看起来好像一样,但是效果是完全不同的,ch 位于
<- 操作符右边的时候, 表示是
有一个简单区分的方法是,将 <- 想象为数据流动的方向,具体来说就是看数据是流向 chan 还是从 chan 流出,流向 chan 就是写入到 chan,从 chan 流出就是读取。
缓冲 chan 与非缓冲 chan
上面我们说到,创建 chan 的时候可以传递第二个参数表示
chan 的容量是多少,这个容量表示的是, 在没有 goroutine
从这个 chan 读取数据的时候,chan
能存放多少数据,也就是 chan 底层环形队列的长度。
下面描述了缓冲的实际场景:
无缓冲 chan
还是用我们上面的那段代码:
1 | package main |
这里 make(chan struct{}),只有一个参数,所以
done 是一个无缓冲的 chan,这种
chan 会在发送的时候阻塞,直到有另一个协程从
chan 中获取数据。

有缓冲 chan
有缓冲的 chan
在协程往里面写入数据的时候,可以进行缓冲。缓冲的作用是,在需要读取
chan 的 goroutine 的处理速度比较慢的时候,写入
chan 的 goroutine 也可以持续运行,直到写满
chan 的缓冲区

上图的 chan 是一个有缓冲的 chan,在
chan 里面的数据还没来得及被接收的时候,chan
可以充当一个缓冲的角色。但是,如果 chan
的数据一直没有被接收,然后满了的时候,往 chan
写入数据的协程依然会陷入阻塞。但这种阻塞状态会在 chan
的数据被读取的时候解除。
下面是一个例子:
1 | package main |
输出如下:
1 | [1669381752] write to ch: 0 |
我们可以看到,写入 chan 的协程在 1669381752
的时候没有写入了,然后在读取 chan 的协程从
chan 中读取了一个数出来后才能继续写入。
nil chan
chan 的零值是 nil,close 一个
nil 通道会引发 panic。往 nil
通道写入或从中读取数据会永久阻塞:
1 | package main |
执行的时候会报错:fatal error: all goroutines are asleep - deadlock!
len 和 cap
len:通过len我们可以查询一个chan的长度,也就是有多少被发送到这个chan但是还没有被接收的值。cap:通过cap可以查询一个容道的容量,也就是我们传给make函数的第二个参数,它表示chan最多可以容纳多少数据。
如果
chan是nil,那么len和cap都会返回 0。
chan 的方向
chan
还有一个非常重要的特性就是它是可以有方向的,这里说的方向指的是,数据的流向。在我们上面的例子中,数据既可以流入
chan,也可以从 chan
中流出,因为我们没有指定方向,没有指定那么 chan
就是双向的。
具体来说,有以下几种情况:
chan,没有指定方向,既可以读又可以写。chan<-,只写chan,只能往chan中写入数据,如果从中读数据的话,编译不会通过。<-chan,只读chan,只能从chan中读取数据,如果往其中写入数据的话,编译不会通过。
另外,无方向的 chan 可以转换为
chan<- 或者
<-chan,但是反过来不行
在实际使用 chan 的时候,在某些地方我们其实是只允许往
chan 里面写数据,然后另一个地方只允许从 chan
中读数据。比如下面这个例子:
1 | package main |
在这个例子中,producer 这个协程里面往 chan
写入数据,写入 3 个数之后关闭,然后 consumer 这个协程序从
chan 读取数据, 在读取完所有数据之后,发送结束信号(通过
done 这个 chan),最后 main
协程收到 done 信号后退出。
这样有个好处就是,从语法层面限制了对 chan 的读写操作。而不用担心有误操作。
什么时候阻塞?什么时候不阻塞?
在开始这个话题之前,很有必要说一下,go 里面 chan
的一些实现原理,在 chan 的实现中,维护了三个队列:
- 数据缓冲队列(
chan):也就是上面说的环形队列,是一种先进先出结构(FIFO,"First In, First Out"),它的长度是chan的容量。此队列存放的都是同一种类型的元素。 - 接收数据协程队列(
recvq):当chan里面没有数据可以读取的时候,这个队列会有数据,这个队列中的协程都在等待从chan中读取数据。 - 发送数据协程队列(
sendq):当数据缓冲队列满了的时候(又或者如果是一个无缓冲的chan),那么这个队列不为空,这个队列中的协程都在等待往chan中写入数据。
大家在实际使用的时候可以参考一下下图,下图列出了对 chan
操作的所有场景:

对于阻塞或者非阻塞,其实有一个很简单的判断标准,下面描述了所有会阻塞的情况:
- 发送:如果没有地方能存放发送的数据,则阻塞,具体有下面几种情况:
nil chan- 有缓冲但是缓冲满了
- 无缓冲并且没有协程在等待从
chan中读取数据
- 接收:如果没有可以读取的数据,则阻塞,具体有下面几种情况:
nil chan- 有缓冲,但是缓冲区空的
- 无缓冲,但是没有协程正在往
chan中发送数据
大家觉得抽象可以结合下面这个图想象一下:

结合现实场景想象一下,我们可以把 chan
想象成为配送员,sendq 想象为商家,recvq
想象成用户,配送员装餐点的箱子想象成缓冲区:
一个假设的前提:假设商家只能在送出去一份餐点后,才能开始制作下一份餐点。
- 发送
nil chan。没有配送员了,商家的餐点肯定是送不出去了,商家只能等着关门大吉了。- 有缓冲但是缓冲满了。配送员会有一个箱子(缓冲区)来存放外卖,但是这个箱子现在满了,虽然接了一个单,但是没有办法再从商家那里取得外卖来送了
- 无缓冲并且没有协程在等待从
chan中读取数据。这个外卖是用户自取的订单,但是用户联系不上。(当然现实中商家不用等,我们假设现在商家只能送出去一份后才能开始制作下一份)
- 接收
nil chan。没有配送员,用户的餐没人送,用户只能等着饿死了。- 有缓冲,但是缓冲区空的。商家还没制作好餐点,配送员没有取到餐,这个时候用户打电话给配送员叫他快点送,但是这个时候配送员也没有办法,因为他也没有拿到用户的餐点。这个时候用户快饿死了,但也没有办法,只有干等着,先吃饱才能搬砖。
- 无缓冲,但是没有协程正在往
chan中发送数据。这天,用户是下了自取的订单,然后去到店里的时候,商家还没做好,这个时候,用户啥事也干不了,也只能等了。
需要注意的是,上图中发送和接收只有一个协程,但是在实际中,正如这一节开头讲的那样,发送和接收都维护了一个队列的。 对应到上面那个现实的例子,那就是配送员可以同时从多个商家那里取餐,也可以同时给多个用户送餐,这个过程,有可能多个商家在制作需要这个配送员配送的餐点,也有可能有多个用户在等着这个配送员送餐。
<- 操作符只是语法糖
在 go 里面我们操作 chan 的方式好像非常简单,就通过
<- 操作符就已经绰绰有余了,这也是 go
的设计理念吧,尽量把语言设计得简单。
(但是,简单并不容易)但是,从另外一个角度看,go 把对
chan 的操作简化成我们现在看到的这个样子,也说明了
chan 在 go 里面的地位(一等公民)。
在 go 中,chan
实际上是一个结构体(runtime/chan.go 里面的
hchan
结构体),而且,还是一个非常复杂的结构体,但是我们在使用的时候却非常简单,
这其实是 go
设计者给开发者提供的一种语法糖,直接在语法层面极大地简化了开发者对
chan 的使用,
如果没有这个语法糖,那就需要开发者自己去创建 hchan
结构体,然后发送或者接收的时候还需要调用这个结构体的方法。
相比之下,<-
就写一个操作符就行了,而且这个符号还非常形象,指向哪就代表了数据是流向
chan (写)还是从 chan 流出(读)。
for...range 语法糖
我们上面说过了,从 chan
读取数据的时候,可能需要用两个值来接收 chan
的返回值,第二个值用来判断接收到的值是否是 chan
关闭之前发送的。
而 for...range 语法也可以用来从 chan
中读取数据,它会循环,直到 chan
关闭,这样直接免去了我们判断的操作,比如:
1 | package main |
select 语句里面使用 chan
go 里面有一个关键字 select,可以让我们同时监听几个
chan,在任意一个 chan
有数据的时候,select 里面的 case
块得以执行:
1 | package main |
select-case 的用法类似于
switch-case,也有一个 default 语句,在
select 里面
- 如果
default之前的case都不满足,则执行default块的代码。 - 如果没有
default语句,则会一直阻塞,直到某一个case上面的chan返回(有数据、或者chan被关闭都会返回)
当然,case 后面可以从 chan
读取数据,也可以往 chan 写数据,比如:
1 | package main |
select 的另外一种很常见的用法是,等待一个
chan 和一个定时器(实现控制超时的功能),比如:
1 | package main |
如果我们需要控制某些操作的超时时间,那么就可以在时间到了之后,做一些清理操作,然后终止一些工作,最后退出协程。
总结
- go 里面通过
chan来实现协程之间的通信,chan大概就是一个协程给另一个协程发送信息的代理。 - 多线程程序执行的时候,因为有 CPU 缓存,然后需要对同一块内存进行并发读写,可能会导致数据竞争的问题。
- 在很多语言中,都提供了锁的机制,来保护一片内存同一时刻只能一个线程操作,比如
java 里面的
synchronized关键字。 - go 里面很多情况下,在不同协程之间通信都是使用
chan来实现的。 - 进程会有阻塞态、运行态,go
里面的协程也有阻塞的状态,当需要的资源得不到满足的时候就会陷入阻塞。比如等待别的协程往
chan里面写入数据。 chan的几种常见操作:make创建、<-chan读、chan<-写、len获取chan中未读取的元素个数、cap获取chan的缓冲区容量。chan类型上不加<-表示是一个可读可写的chan,<-chan T表示只读chan,chan<- T表示只写chan,双向的chan可以转换为只读或者只写chan,但是反过来不行,只读chan和只写chan之间也不能相互转换。- 协程的阻塞跟不阻塞,很简单的判断方式就是,发送的时候就看有没有地方能接得住,接收的时候就看有没有数据可以拿,没有则陷入阻塞。
<-是 go 语言在设计层面提供给开发者的一种语法糖,chan底层是一个很复杂的结构体。for...range结构在遍历chan的时候不用判断返回值是否有效,因为返回值无效的时候会退出循环。- 我们可以通过
select来同时等待多个chan的操作返回。