Go的channel提供了強(qiáng)大的同步功能，那么如何使用channel交叉打印兩個(gè)數(shù)組呢？
數(shù)組1打印完一個(gè)值就用channel通知數(shù)組2，同理數(shù)組2打印完一個(gè)值用另一個(gè)channel通知數(shù)組1，即可實(shí)現(xiàn)同步
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;i5;i++{
ch1-i
fmt.Print(i+1)
-ch2
}
}()
for _,v :=range str{
-ch1
fmt.Print(v)
ch2-v
}
}
結(jié)果：
1a2b3c4d5e
Process finished with exit code 0
補(bǔ)充：使用golang的channel的坑
很多時(shí)候我們經(jīng)過使用有緩沖channel作為通信控制的功能，以至有一些誤解和坑出現(xiàn)。
執(zhí)行下面代碼：
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)
}
}
}
多執(zhí)行幾次看看結(jié)果，并不是每一次都是可以順序輸出的，有緩存channel是亂序的。因?yàn)檫@里讓一些同學(xué)誤解了，我在此多解釋一下。
針對(duì)通道的發(fā)送和接收操作都是可能造成相關(guān)的goroutine阻塞。
試想一下，有多個(gè)goroutine向同一個(gè)channel發(fā)送數(shù)據(jù)而被阻塞，如果還channel有多余的緩存空間時(shí)候，最早被阻塞的goroutine會(huì)最先被喚醒。
也就是說，這里的喚醒順序與發(fā)送操作的開始順序是一致的，對(duì)接收操作而言亦為如此。無論是發(fā)送還是接收操作，運(yùn)行時(shí)系統(tǒng)每次只會(huì)喚醒一個(gè)goroutine。
而這里的亂序是指，如果像使用channel緩存中多個(gè)goroutine實(shí)現(xiàn)順序是正確的，因?yàn)槊恳粋€(gè)goroutine搶到處理器的時(shí)間點(diǎn)不一致，所以不能保證順序。
如下代碼：
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 的技術(shù)選型比較激進(jìn)，比如依賴了 HLC 來做事務(wù)的時(shí)間戳。但是在 Spanner 的事務(wù)模型的 Commit Wait 階段等待時(shí)間的選擇，CockroachDB 并沒有辦法做到 10ms 內(nèi)的延遲；CockroachDB 的 Commit Wait 需要用戶自己指定，但是誰能拍胸脯說 NTP 的時(shí)鐘誤差在多少毫秒內(nèi)？我個(gè)人認(rèn)為在處理跨洲際機(jī)房時(shí)鐘同步的問題上，基本只有硬件時(shí)鐘一種辦法。HLC 是沒辦法解決的。另外 Cockroach 采用了 gossip 來同步節(jié)點(diǎn)信息，當(dāng)集群變得比較大的時(shí)候，gossip 心跳會(huì)是一個(gè)非常大的開銷。當(dāng)然 CockroachDB 的這些技術(shù)選擇帶來的優(yōu)勢(shì)就是非常好的易用性，所有邏輯都在一個(gè) binary 中，開箱即用，這個(gè)是非常大的優(yōu)點(diǎn)。"
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()
}
}()
}
}
很多同學(xué)乍一看以為定義了
bf := make(chan string, 64)
就是說該程序的并發(fā)度控制在了64，執(zhí)行就會(huì)發(fā)現(xiàn)內(nèi)存一直在增長(zhǎng)。
因?yàn)間et()函數(shù)中啟動(dòng)的goroutine會(huì)越來越多，因?yàn)間et()每讀取一個(gè)數(shù)據(jù)，insert()就會(huì)往channel插入一條數(shù)據(jù)，此時(shí)并發(fā)度就不是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;i64;i++ { go get1(bf)
}
wg.Wait()
}func insert(bf chan string) {
str := "CockroachDB 的技術(shù)選型比較激進(jìn)，比如依賴了 HLC 來做事務(wù)的時(shí)間戳。但是在 Spanner 的事務(wù)模型的 Commit Wait 階段等待時(shí)間的選擇，CockroachDB 并沒有辦法做到 10ms 內(nèi)的延遲；CockroachDB 的 Commit Wait 需要用戶自己指定，但是誰能拍胸脯說 NTP 的時(shí)鐘誤差在多少毫秒內(nèi)？我個(gè)人認(rèn)為在處理跨洲際機(jī)房時(shí)鐘同步的問題上，基本只有硬件時(shí)鐘一種辦法。HLC 是沒辦法解決的。另外 Cockroach 采用了 gossip 來同步節(jié)點(diǎn)信息，當(dāng)集群變得比較大的時(shí)候，gossip 心跳會(huì)是一個(gè)非常大的開銷。當(dāng)然 CockroachDB 的這些技術(shù)選擇帶來的優(yōu)勢(shì)就是非常好的易用性，所有邏輯都在一個(gè) binary 中，開箱即用，這個(gè)是非常大的優(yōu)點(diǎn)。"
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()
}
}
}
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。
標(biāo)簽：銅川 吐魯番 梅河口 雞西 重慶 汕頭 欽州 蘭州
巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《使用Golang的channel交叉打印兩個(gè)數(shù)組的操作》，本文關(guān)鍵詞 使用,Golang,的,channel,交叉,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。
