充分发挥渠道的作用

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《充分发挥渠道的作用》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

我在 uber 的风格指南中读到，最多应使用 1 的通道长度。

虽然我很清楚使用 100 或 1000 的通道大小是非常糟糕的做法，但我想知道为什么通道大小 10 不被认为是有效的选项。我遗漏了一些部分来得出正确的结论。

下面，您可以遵循我的论点（以及反论点），并得到一些基准测试的支持。

据我了解，如果负责从此通道写入或读取的两个 go 例程在顺序写入或读取通道之间被其他 io 操作打断，则不会有任何增益更高的通道缓冲区，我同意 1 是最佳选择。

但是，可以说，除了因向通道写入/从通道读取而导致的隐式锁定和解锁之外，不需要其他重要的 go 例程切换。然后我得出以下结论：

在通道缓冲区大小为 1 和 10 (gr = go-routine) 的通道上处理 100 个值时，请考虑上下文切换的数量

• buffer=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 的通道，例如如果该通道用作信号量。

您阅读的样式指南建议不要使用 cap 64 的缓冲通道，“因为这看起来是一个不错的数字”。但这个建议不是因为性能！ （顺便说一句：你的微基准是无用的微基准，它们不测量任何相关的东西。）

无缓冲通道是某种同步原语，非常有用。

缓冲通道可能会在发送方和接收方之间进行缓冲，并且这种缓冲对于观察代码、调整和调试代码来说可能会出现问题（因为创造和消费进一步解耦）。这就是为什么风格指南建议使用无缓冲通道（或者最多上限为 1，因为有时需要这样做才能保证正确性！）。

它也不禁止更大的缓冲区上限：

任何其他 [0 或 1] 大小都必须受到高水平的审查。考虑如何确定大小，什么可以防止通道在负载下填满并阻塞写入器，以及发生这种情况时会发生什么。 [强调。我的]

如果您可以解释为什么是 27（而不是 22 或 31）以及这将如何影响程序行为（不仅仅是性能！），您可以使用 27 的上限。如果缓冲区已满。

大多数人都高估了绩效。正确性、运行稳定性和可维护性是第一位的。这就是本风格指南的目的。

好了，本文到此结束，带大家了解了《充分发挥渠道的作用》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！