mirror of
https://github.com/gopl-zh/gopl-zh.github.com.git
synced 2024-12-27 07:16:22 +00:00
85 lines
6.3 KiB
Markdown
85 lines
6.3 KiB
Markdown
### 8.4.4. 带缓存的Channels
|
||
|
||
带缓存的Channel内部持有一个元素队列。队列的最大容量是在调用make函数创建channel时通过第二个参数指定的。下面的语句创建了一个可以持有三个字符串元素的带缓存Channel。图8.2是ch变量对应的channel的图形表示形式。
|
||
|
||
```Go
|
||
ch = make(chan string, 3)
|
||
```
|
||
|
||
|
||
|
||
向缓存Channel的发送操作就是向内部缓存队列的尾部插入元素，接收操作则是从队列的头部删除元素。如果内部缓存队列是满的，那么发送操作将阻塞直到因另一个goroutine执行接收操作而释放了新的队列空间。相反，如果channel是空的，接收操作将阻塞直到有另一个goroutine执行发送操作而向队列插入元素。
|
||
|
||
我们可以在无阻塞的情况下连续向新创建的channel发送三个值：
|
||
|
||
```Go
|
||
ch <- "A"
|
||
ch <- "B"
|
||
ch <- "C"
|
||
```
|
||
|
||
此刻，channel的内部缓存队列将是满的（图8.3），如果有第四个发送操作将发生阻塞。
|
||
|
||
|
||
|
||
如果我们接收一个值，
|
||
|
||
```Go
|
||
fmt.Println(<-ch) // "A"
|
||
```
|
||
|
||
那么channel的缓存队列将不是满的也不是空的（图8.4），因此对该channel执行的发送或接收操作都不会发生阻塞。通过这种方式，channel的缓存队列解耦了接收和发送的goroutine。
|
||
|
||
|
||
|
||
在某些特殊情况下，程序可能需要知道channel内部缓存的容量，可以用内置的cap函数获取：
|
||
|
||
```Go
|
||
fmt.Println(cap(ch)) // "3"
|
||
```
|
||
|
||
同样，对于内置的len函数，如果传入的是channel，那么将返回channel内部缓存队列中有效元素的个数。因为在并发程序中该信息会随着接收操作而失效，但是它对某些故障诊断和性能优化会有帮助。
|
||
|
||
```Go
|
||
fmt.Println(len(ch)) // "2"
|
||
```
|
||
|
||
在继续执行两次接收操作后channel内部的缓存队列将又成为空的，如果有第四个接收操作将发生阻塞：
|
||
|
||
```Go
|
||
fmt.Println(<-ch) // "B"
|
||
fmt.Println(<-ch) // "C"
|
||
```
|
||
|
||
在这个例子中，发送和接收操作都发生在同一个goroutine中，但是在真实的程序中它们一般由不同的goroutine执行。Go语言新手有时候会将一个带缓存的channel当作同一个goroutine中的队列使用，虽然语法看似简单，但实际上这是一个错误。Channel和goroutine的调度器机制是紧密相连的，如果没有其他goroutine从channel接收，发送者——或许是整个程序——将会面临永远阻塞的风险。如果你只是需要一个简单的队列，使用slice就可以了。
|
||
|
||
下面的例子展示了一个使用了带缓存channel的应用。它并发地向三个镜像站点发出请求，三个镜像站点分散在不同的地理位置。它们分别将收到的响应发送到带缓存channel，最后接收者只接收第一个收到的响应，也就是最快的那个响应。因此mirroredQuery函数可能在另外两个响应慢的镜像站点响应之前就返回了结果。（顺便说一下，多个goroutines并发地向同一个channel发送数据，或从同一个channel接收数据都是常见的用法。）
|
||
|
||
```Go
|
||
func mirroredQuery() string {
|
||
responses := make(chan string, 3)
|
||
go func() { responses <- request("asia.gopl.io") }()
|
||
go func() { responses <- request("europe.gopl.io") }()
|
||
go func() { responses <- request("americas.gopl.io") }()
|
||
return <-responses // return the quickest response
|
||
}
|
||
|
||
func request(hostname string) (response string) { /* ... */ }
|
||
```
|
||
|
||
如果我们使用了无缓存的channel，那么两个慢的goroutines将会因为没有人接收而被永远卡住。这种情况，称为goroutines泄漏，这将是一个BUG。和垃圾变量不同，泄漏的goroutines并不会被自动回收，因此确保每个不再需要的goroutine能正常退出是重要的。
|
||
|
||
关于无缓存或带缓存channels之间的选择，或者是带缓存channels的容量大小的选择，都可能影响程序的正确性。无缓存channel更强地保证了每个发送操作与相应的同步接收操作；但是对于带缓存channel，这些操作是解耦的。同样，即使我们知道将要发送到一个channel的信息的数量上限，创建一个对应容量大小的带缓存channel也是不现实的，因为这要求在执行任何接收操作之前缓存所有已经发送的值。如果未能分配足够的缓存将导致程序死锁。
|
||
|
||
Channel的缓存也可能影响程序的性能。想象一家蛋糕店有三个厨师，一个烘焙，一个上糖衣，还有一个将每个蛋糕传递到它下一个厨师的生产线。在狭小的厨房空间环境，每个厨师在完成蛋糕后必须等待下一个厨师已经准备好接受它；这类似于在一个无缓存的channel上进行沟通。
|
||
|
||
如果在每个厨师之间有一个放置一个蛋糕的额外空间，那么每个厨师就可以将一个完成的蛋糕临时放在那里而马上进入下一个蛋糕的制作中；这类似于将channel的缓存队列的容量设置为1。只要每个厨师的平均工作效率相近，那么其中大部分的传输工作将是迅速的，个体之间细小的效率差异将在交接过程中弥补。如果厨师之间有更大的额外空间——也是就更大容量的缓存队列——将可以在不停止生产线的前提下消除更大的效率波动，例如一个厨师可以短暂地休息，然后再加快赶上进度而不影响其他人。
|
||
|
||
另一方面，如果生产线的前期阶段一直快于后续阶段，那么它们之间的缓存在大部分时间都将是满的。相反，如果后续阶段比前期阶段更快，那么它们之间的缓存在大部分时间都将是空的。对于这类场景，额外的缓存并没有带来任何好处。
|
||
|
||
生产线的隐喻对于理解channels和goroutines的工作机制是很有帮助的。例如，如果第二阶段是需要精心制作的复杂操作，一个厨师可能无法跟上第一个厨师的进度，或者是无法满足第三阶段厨师的需求。要解决这个问题，我们可以再雇佣另一个厨师来帮助完成第二阶段的工作，他执行相同的任务但是独立工作。这类似于基于相同的channels创建另一个独立的goroutine。
|
||
|
||
我们没有太多的空间展示全部细节，但是gopl.io/ch8/cake包模拟了这个蛋糕店，可以通过不同的参数调整。它还对上面提到的几种场景提供对应的基准测试（§11.4） 。
|
||
|
||
|