使用golang的channel的坑

梦朝思夕 · · 3088 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

很多时候我们经过使用有缓冲channel作为通信控制的功能,以至有一些误解和坑出现。

误解一:有缓存channel是顺序的

执行下面代码。

package main

import (
    "time"
    "math/rand"
)

func main(){
    cache:=make(chan int,4)
    go func() {
        for i:=0;i< 10;i++ {
            cache<-i
        }
    }()
    go getCache(cache)
    go getCache(cache)
    go getCache(cache)
    time.Sleep(3*time.Second)
}

func getCache(cache <-chan int)  {
    for  {
        select {
        case i:=<-cache:
            println(i)
            time.Sleep(time.Duration(rand.Int31n(100))*time.Millisecond)
        }
    }

}

多执行几次看看结果,并不是每一次都是可以顺序输出的,有缓存channel是乱序的。

误解二:channel缓存的大小就是并发度

如下代码。

package main

import (
	"fmt"
	"sync"
	"time"
)

var wg = sync.WaitGroup{}

func main() {
	wg.Add(2)
	bf := make(chan string, 64)
	go insert(bf)
	go get(bf)
	wg.Wait()
}
func insert(bf chan string) {
	str := "CockroachDB 的技术选型比较激进,比如依赖了 HLC 来做事务的时间戳。但是在 Spanner 的事务模型的 Commit Wait 阶段等待时间的选择,CockroachDB 并没有办法做到 10ms 内的延迟;CockroachDB 的 Commit Wait 需要用户自己指定,但是谁能拍胸脯说 NTP 的时钟误差在多少毫秒内?我个人认为在处理跨洲际机房时钟同步的问题上,基本只有硬件时钟一种办法。HLC 是没办法解决的。另外 Cockroach 采用了 gossip 来同步节点信息,当集群变得比较大的时候,gossip 心跳会是一个非常大的开销。当然 CockroachDB 的这些技术选择带来的优势就是非常好的易用性,所有逻辑都在一个 binary 中,开箱即用,这个是非常大的优点。"
	for i := 0; i < 10000000; i++ {
		bf <- fmt.Sprintf("%s%d", str, i)
	}
	wg.Done()
}

func sprint(s string) {
	time.Sleep(1000 * time.Millisecond)
}

func get(bf chan string) {
	for {
		go func() {

			select {
			case str := <-bf:
				sprint(str)
			case <-time.After(3 * time.Second):
				wg.Done()
			}

		}()
	}
}

很多同学乍一看以为定义了

bf := make(chan string, 64)

就是说该程序的并发度控制在了64,执行就会发现内存一直在增长。 因为get()函数中启动的goroutine会越来越多,因为get()每读取一个数据,insert()就会往channel插入一条数据,此时并发度就不是64了。 需要修改为:

package main

import (
	"fmt"
	"sync"
	"time"
)

var wg = sync.WaitGroup{}

func main() {
	wg.Add(2)
	bf := make(chan string, 64)
	go insert(bf)
	//go get(bf)
    for i:=0;i<64;i++ {
        go get1(bf)
    }

	wg.Wait()
}
func insert(bf chan string) {
	str := "CockroachDB 的技术选型比较激进,比如依赖了 HLC 来做事务的时间戳。但是在 Spanner 的事务模型的 Commit Wait 阶段等待时间的选择,CockroachDB 并没有办法做到 10ms 内的延迟;CockroachDB 的 Commit Wait 需要用户自己指定,但是谁能拍胸脯说 NTP 的时钟误差在多少毫秒内?我个人认为在处理跨洲际机房时钟同步的问题上,基本只有硬件时钟一种办法。HLC 是没办法解决的。另外 Cockroach 采用了 gossip 来同步节点信息,当集群变得比较大的时候,gossip 心跳会是一个非常大的开销。当然 CockroachDB 的这些技术选择带来的优势就是非常好的易用性,所有逻辑都在一个 binary 中,开箱即用,这个是非常大的优点。"
	for i := 0; i < 10000000; i++ {
		bf <- fmt.Sprintf("%s%d", str, i)
	}
	wg.Done()
}

func sprint(s string) {
	time.Sleep(1000 * time.Millisecond)
}

func get1(bf chan string)  {
    for {
        select {
        case str := <-bf:
            sprint(str)
        case <-time.After(3 * time.Second):
            wg.Done()
        }
    }
}

有疑问加站长微信联系(非本文作者)

本文来自:开源中国博客

感谢作者:梦朝思夕

查看原文:使用golang的channel的坑

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

3088 次点击  
加入收藏 微博
5 回复  |  直到 2019-12-18 15:39:10
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传