Rob Pike 在 Google I/O 2012 - Go Concurrency Patterns 里演示了一个例子(daisy chain)。 视频地址:https://www.youtube.com/watch?v=f6kdp27TYZs
这个例子抽象于“传话游戏”,几个人站成一队,第一个人跟第二个人悄悄说一句话,依次传到最后一个人,看看最后一个人听到的和第一个人说的差别有多大。
代码如下:
package main import "fmt" func pass(left, right chan int){
left <- 1 + <- right
} func main(){
const n = 50
leftmost := make(chan int)
right := leftmost
left := leftmost for i := 0; i< n; i++ {
right = make(chan int)
// the chain is constructed from the end
go pass(left, right) // the first goroutine holds (leftmost, new chan)
left = right // the second and following goroutines hold (last right chan, new chan)
}
go func(c chan int){ c <- 1}(right)
fmt.Println("sum:", <- leftmost)
}
这段代码产生了一个单向的管道环,每个节点对输入的值加了1,然后输出给下一个节点,最后到终点 leftmost。重点我认为有以下几个:
1,循环中的 goroutine ;
2,unbuffered channel 的连接和阻塞;
3,goroutine 对 channel 的竞争;
第一点:循环中的 goroutine 其实很像 js 中的循环中的异步请求,或者更直观的,像是循环中的 setTimeout()。对于 main 来说,goroutine 是异步的,是对线程的细粒度抽象,把它当做一个异步任务就可以了。但是包含了 channel 的 goroutine 就有了阻塞的成分。channel 也体现了 Golang 的设计理念之一:Do not communicate by sharing memory; instead, share memory by communicating 。
第二点:unbuffered channel (make(chan int)) 可以看做是非常短的管子,里面连一个字节都不能存储,必须先找到两端的输入和输出,不然就会出问题(阻塞)。比如下面代码:
func main(){
c := make(chan int)
c <- 1
fmt.Println( <- c)
} // fatal error: all goroutines are asleep - deadlock!
上面的代码中, c <- 1 这一行给 channel 输入了数据,但是此时还没有接收者(代码是同步执行的),因此卡死在这儿了。
那如果先给 channel 指定了输出,然后再输入数据呢? 结果是一样的,只有接收者没有输入者,一样卡死。
改成这样就可以了:
func main(){
c := make(chan int)
go func(){fmt.Println(<- c)}()
c <- 1
}
这里先在 goroutine 里指定了 Println 作为接收者,然后给了输入。
可以理解为:channel 不能同时输入和输出, <- c <- 1 会报错(可能 Golang 觉得这样是没有意义的);指定输入和输出必须写在两行,而代码的同步执行决定了不能同时指定输入和输出,因此只能用 goroutine 。实际上 channel 本身也是为了 goroutine 间的通讯。
buffered channel 就比较好理解,是带有容器的管道,可以存储一定数量的数据。但是当容器满的时候,表现就和 unbuffered channel 一样,会阻塞。
第三点:第一块代码里产生的管道环是从终点开始连接起的,最后一根管道实际上是数据流的第一节管道。在这个环刚完成的时候,所有管道都是空的,没有输入。这时所有的 goroutine 都被阻塞了,倒数第三行的 go 给了第一个管道一个输入,于是这点数据就流到了最后。