使用Golang的channel交叉打印两个数组的操作

时间:2022-10-29 23:12:46

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