如何有效利用渠道
我在Uber 的风格指南上读到,一个人最多应该使用 1 的通道长度。
虽然我很清楚使用 100 或 1000 的通道大小是非常糟糕的做法,但我想知道为什么通道大小为 10 不被视为有效选项。我错过了一些部分来得出正确的结论。
在下面,您可以遵循由一些基准测试支持的我的论点(和反论点)。
我知道,如果您负责从该通道写入或读取的两个 go-routines 将在顺序写入或读取到/从通道之间被其他一些 IO 操作中断,则预计不会从更高的通道获得收益缓冲,我同意 1 是最好的选择。
但是,可以说,除了由通道写入/读取引起的隐式锁定和解锁之外,不需要其他重要的 go-routine 切换。那么我总结如下:
在使用大小为 1 和 10 的通道缓冲区(GR = go-routine)的通道上处理 100 个值时,考虑上下文切换的数量
- 缓冲区=1:(GR1 插入 1 个值,GR2 读取 1 个值)X 100 ~ 200 个 go-routine 切换
- Buffer=10:(GR1 插入 10 个值,GR2 读取 10 个值)X 10 ~ 20 个 go-routine 开关
我做了一些基准测试来证明这实际上速度更快:
package main
import (
"testing"
)
type a struct {
b [100]int64
}
func BenchmarkBuffer1(b *testing.B) {
count := 0
c := make(chan a, 1)
go func() {
for i := 0; i < b.N; i++ {
c <- a{}
}
close(c)
}()
for v := range c {
for i := range v.b {
count += i
}
}
}
func BenchmarkBuffer10(b *testing.B) {
count := 0
c := make(chan a, 10)
go func() {
for i := 0; i < b.N; i++ {
c <- a{}
}
close(c)
}()
for v := range c {
for i := range v.b {
count += i
}
}
}
比较简单读写+非阻塞处理的结果:
BenchmarkBuffer1-12 5072902 266 ns/op
BenchmarkBuffer10-12 6029602 179 ns/op
PASS
BenchmarkBuffer1-12 5228782 256 ns/op
BenchmarkBuffer10-12 5392410 216 ns/op
PASS
BenchmarkBuffer1-12 4806208 287 ns/op
BenchmarkBuffer10-12 4637842 233 ns/op
PASS
但是,如果我每读取 10 次就添加一次睡眠,则不会产生更好的结果。
import (
"testing"
"time"
)
func BenchmarkBuffer1WithSleep(b *testing.B) {
count := 0
c := make(chan int, 1)
go func() {
for i := 0; i < b.N; i++ {
c <- i
}
close(c)
}()
for a := range c {
count++
if count%10 == 0 {
time.Sleep(time.Duration(a) * time.Nanosecond)
}
}
}
func BenchmarkBuffer10WithSleep(b *testing.B) {
count := 0
c := make(chan int, 10)
go func() {
for i := 0; i < b.N; i++ {
c <- i
}
close(c)
}()
for a := range c {
count++
if count%10 == 0 {
time.Sleep(time.Duration(a) * time.Nanosecond)
}
}
}
每 10 次读取一次睡眠时的结果:
BenchmarkBuffer1WithSleep-12 856886 53219 ns/op
BenchmarkBuffer10WithSleep-12 929113 56939 ns/op
仅供参考:我也只用一个 CPU 再次进行了测试,得到了以下结果:
BenchmarkBuffer1 5831193 207 ns/op
BenchmarkBuffer10 6226983 180 ns/op
BenchmarkBuffer1WithSleep 556635 35510 ns/op
BenchmarkBuffer10WithSleep 984472 61434 ns/op
回答
绝对没有问题的上限 500 通道,例如,如果该通道用作信号量。
您阅读的样式指南建议不要使用缓冲通道,假设上限为 64,“因为这看起来是一个不错的数字”。但是这个建议不是因为性能!(顺便说一句:你的微基准是无用的微基准,它们不衡量任何相关的东西。)
无缓冲通道是某种同步原语,对我们来说非常有用。
一个缓冲的通道可能会在发送方和接收方之间进行缓冲,并且这种缓冲对于观察、调整和调试代码可能是有问题的(因为创建和消费是进一步解耦的)。这就是为什么风格指南推荐无缓冲通道(或最多 1 个上限,因为有时需要正确性!)。
它也不禁止更大的缓冲区上限:
任何其他 [非 0 或 1] 大小都必须经过高度审查。考虑如何确定大小,防止通道在负载下填满和阻塞写入器的原因,以及发生这种情况时会发生什么。[嗯。矿]
如果您能解释为什么是 27(而不是 22 或 31)以及如果缓冲区已满,这将如何影响程序行为(不仅是性能!),您可以使用上限为 27 。
大多数人高估了性能。正确性、运行稳定性和可维护性是第一位的。这就是本风格指南的内容。