使用golang的channel的坑

前端之家收集整理的这篇文章主要介绍了使用golang的channel的坑前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

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

执行下面代码

packagemainimport("time"
"math/rand")funcmain(){
cache:=make(chanint,4)gofunc(){fori:=0;i<10;i++{
cache<-i
}
}()gogetCache(cache)gogetCache(cache)gogetCache(cache)
time.Sleep(3*time.Second)
}funcgetCache(cache<-chanint){for{select{casei:=<-cache:println(i)
time.Sleep(time.Duration(rand.Int31n(100))*time.Millisecond)
}
}

}@H_404_7@ 

多执行几次看看结果,并不是每一次都是可以顺序输出的,有缓存channel是乱序的。因为这里让一些同学误解了,我在此多解释一下。
针对通道的发送和接收操作都是可能造成相关的goroutine阻塞。试想一下,有多个goroutine向同一个channel发送数据而被阻塞,如果还channel有多余的缓存空间时候,最早被阻塞的goroutine会最先被唤醒。也就是说,这里的唤醒顺序与发送操作的开始顺序是一致的,对接收操作而言亦为如此。无论是发送还是接收操作,运行时系统每次只会唤醒一个goroutine。 而这里的乱序是指,如果像使用channel缓存中多个goroutine实现顺序是正确的,因为每一个goroutine抢到处理器的时间点不一致,所以不能保证顺序。

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

如下代码

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

		}()
	}
}@H_404_7@ 

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

bf:=make(chanstring,64)@H_404_7@ 

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

packagemainimport(	"fmt"
	"sync"
	"time")varwg=sync.WaitGroup{}funcmain(){
	wg.Add(2)
	bf:=make(chanstring,64)	goinsert(bf)	//goget(bf)
fori:=0;i<64;i++{goget1(bf)
}

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

猜你在找的Go相关文章