使用Golang的channel交叉打印兩個數(shù)組的操作
Go的channel提供了強(qiáng)大的同步功能,那么如何使用channel交叉打印兩個數(shù)組呢?
灰常簡單,只需設(shè)置兩個channel變量
數(shù)組1打印完一個值就用channel通知數(shù)組2,同理數(shù)組2打印完一個值用另一個channel通知數(shù)組1,即可實現(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;i<5;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的坑
很多時候我們經(jīng)過使用有緩沖channel作為通信控制的功能,以至有一些誤解和坑出現(xiàn)。
誤解一:有緩存channel是順序的
執(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是亂序的。因為這里讓一些同學(xué)誤解了,我在此多解釋一下。
針對通道的發(fā)送和接收操作都是可能造成相關(guān)的goroutine阻塞。
試想一下,有多個goroutine向同一個channel發(fā)送數(shù)據(jù)而被阻塞,如果還channel有多余的緩存空間時候,最早被阻塞的goroutine會最先被喚醒。
也就是說,這里的喚醒順序與發(fā)送操作的開始順序是一致的,對接收操作而言亦為如此。無論是發(fā)送還是接收操作,運(yùn)行時系統(tǒng)每次只會喚醒一個goroutine。
而這里的亂序是指,如果像使用channel緩存中多個goroutine實現(xiàn)順序是正確的,因為每一個goroutine搶到處理器的時間點(diǎn)不一致,所以不能保證順序。
誤解二:channel緩存的大小就是并發(fā)度
如下代碼:
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ù)的時間戳。但是在 Spanner 的事務(wù)模型的 Commit Wait 階段等待時間的選擇,CockroachDB 并沒有辦法做到 10ms 內(nèi)的延遲;CockroachDB 的 Commit Wait 需要用戶自己指定,但是誰能拍胸脯說 NTP 的時鐘誤差在多少毫秒內(nèi)?我個人認(rèn)為在處理跨洲際機(jī)房時鐘同步的問題上,基本只有硬件時鐘一種辦法。HLC 是沒辦法解決的。另外 Cockroach 采用了 gossip 來同步節(jié)點(diǎn)信息,當(dāng)集群變得比較大的時候,gossip 心跳會是一個非常大的開銷。當(dāng)然 CockroachDB 的這些技術(shù)選擇帶來的優(yōu)勢就是非常好的易用性,所有邏輯都在一個 binary 中,開箱即用,這個是非常大的優(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í)行就會發(fā)現(xiàn)內(nèi)存一直在增長。
因為get()函數(shù)中啟動的goroutine會越來越多,因為get()每讀取一個數(shù)據(jù),insert()就會往channel插入一條數(shù)據(jù),此時并發(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;i<64;i++ { go get1(bf) } wg.Wait() }func insert(bf chan string) { str := "CockroachDB 的技術(shù)選型比較激進(jìn),比如依賴了 HLC 來做事務(wù)的時間戳。但是在 Spanner 的事務(wù)模型的 Commit Wait 階段等待時間的選擇,CockroachDB 并沒有辦法做到 10ms 內(nèi)的延遲;CockroachDB 的 Commit Wait 需要用戶自己指定,但是誰能拍胸脯說 NTP 的時鐘誤差在多少毫秒內(nèi)?我個人認(rèn)為在處理跨洲際機(jī)房時鐘同步的問題上,基本只有硬件時鐘一種辦法。HLC 是沒辦法解決的。另外 Cockroach 采用了 gossip 來同步節(jié)點(diǎn)信息,當(dāng)集群變得比較大的時候,gossip 心跳會是一個非常大的開銷。當(dāng)然 CockroachDB 的這些技術(shù)選擇帶來的優(yōu)勢就是非常好的易用性,所有邏輯都在一個 binary 中,開箱即用,這個是非常大的優(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() } } }
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
相關(guān)文章
Go語言中同一個package中函數(shù)互相調(diào)用為undefined的解決
這篇文章主要介紹了Go語言中同一個package中函數(shù)互相調(diào)用為undefined的解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-03-03