使用golang的channel的坑

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

成都创新互联公司是少有的网站设计、网站制作、营销型企业网站、小程序开发、手机APP,开发、制作、设计、买链接、推广优化一站式服务网络公司,自2013年起,坚持透明化,价格低,无套路经营理念。让网页惊喜每一位访客多年来深受用户好评

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

执行下面代码。

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

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

如下代码。

package mainimport (	"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 mainimport (	"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的坑
文章URL：http://scyanting.com/article/gpodgp.html

使用golang的channel的坑

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

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

其他资讯