Go的channel提供了强大的同步功能，那么如何使用channel交叉打印两个数组呢？
灰常简单，只需设置两个channel变量
数组1打印完一个值就用channel通知数组2，同理数组2打印完一个值用另一个channel通知数组1，即可实现同步
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
package main import "fmt" func main(){ ch1 :=make(chan int) ch2 :=make(chan string) str :=[5]string{"a","b","c","d","e"} go func() { for i:=0;i<5;i++{ ch1<-i fmt.Print(i+1) <-ch2 } }() for _,v :=range str{ <-ch1 fmt.Print(v) ch2<-v }} |
结果：
1a2b3c4d5e
Process finished with exit code 0
补充：使用golang的channel的坑
很多时候我们经过使用有缓冲channel作为通信控制的功能，以至有一些误解和坑出现。
误解一：有缓存channel是顺序的
执行下面代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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缓存的大小就是并发度
如下代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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() } }() }} |
很多同学乍一看以为定义了
|
1
|
bf := make(chan string, 64) |
就是说该程序的并发度控制在了64，执行就会发现内存一直在增长。
因为get()函数中启动的goroutine会越来越多，因为get()每读取一个数据，insert()就会往channel插入一条数据，此时并发度就不是64了。
需要修改为：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
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() } }} |
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。如有错误或未考虑完全的地方，望不吝赐教。
原文链接：https://blog.csdn.net/cxzzxc123456/article/details/81514927
