go channel

信道產生的動機：在 Go 語言中，一個最多見的也是常常被人說起的設計模式就是不要經過共享內存的方式進行通訊，而是應該經過通訊的方式共享內存，信道就是爲此而生

信道的聲明：

方法1：var   a   chan  int      信道的零值爲nil

方法2：a :=make(chan,int)   

經過信道發送接收消息：

data :=<-a   讀取信道a的消息

a<- data   向信道a寫入消息

信道的發送和接收都是阻塞的

當把數據發送到信道時，程序控制會在發送數據的語句處發生阻塞，直到有其它 Go 協程從信道讀取到數據，纔會解除阻塞。與此相似，當讀取信道的數據時，若是沒有其它的協程把數據寫入到這個信道，那麼讀取過程就會一直阻塞着。

package main

import (  
    "fmt"
)

func hello(done chan bool) {  
    fmt.Println("Hello world goroutine")
    done <- true  //註釋會死鎖
}
func main() {  
    done := make(chan bool)
    go hello(done)
    <-done  //主協程阻塞
    //close（done）關閉信道
    fmt.Println("main function")
}

串聯信道

咱們能夠經過信道把多個協程串聯起來，一個channel的輸出做爲下一個channel的輸入。

package main

import "fmt"

func main() {
    naturals := make(chan int)
    squares := make(chan int)
    // Counter
    go func() {
        for x := 0; ; x++ {
            naturals <- x
        }
    }()
    // Squarer
    go func() {
        for {
            x := <-naturals
            squares <- x * x
        }
    }()
    // Printer (in main goroutine)
    for {
        fmt.Println(<-squares)
    }
}

單向信道

在上述例子中，squarer函數有兩個channel類型的參數，一個接收數據，一個發送數據，理論上這樣很合理，假如如今來了一個有用心的人，他往應該接收數據的信道中寫入了數據怎麼辦？是否是覺安全堪憂！爲了防止出現狀況，go提供了單向的信道，把channel當作參數，chan <-int 參數 表示一個只發送數據的channel，<-chan int 表示一個只接收數據的channel。

package main

func counter(out chan<- int) {
    for x := 0; x < 100; x++ {
        out <- x
    }
    close(out)
}
func squarer(out chan<- int, in <-chan int) {
    for v := range in {
        out <- v * v
    }
    close(out)
}
func printer(in <-chan int) {
    for v := range in {
        fmt.Println(v)
    }
}
func main() {
    naturals := make(chan int)
    squares := make(chan int)
    go counter(naturals)
    go squarer(squares, naturals)
    printer(squares)
}

帶緩存的信道

帶緩存的Channel內部持有一個元素隊列。隊列的最大容量是在調用make函數建立channel時經過第二個參數指定的。

聲明方式： ch ：=make（chan string ，3）

向緩存Channel的發送操做就是向內部緩存隊列的尾部插入緣由，接收操做則是從隊列的頭部刪除元素。若是內部緩存隊列是滿的，那麼發送操做將阻塞直到因另外一個goroutine執行接收操做而釋放了新的隊列空間。相反，若是channel是空的，接收操做將阻塞直到有另外一個goroutine執行發送操做而向隊列插入元素。

在某些特殊狀況下，程序可能須要知道channel內部緩存的容量，能夠用內置的cap函數獲取：cap(ch)

一樣，對於內置的len函數，若是傳入的是channel，那麼將返回channel內部緩存隊列中有效元素的個數。len(ch)

若是咱們使用了無緩存的channel，那麼兩個慢的goroutines將會由於沒有人接收而被永遠卡住。這種狀況，稱爲goroutines泄漏，這將是一個BUG。和垃圾變量不一樣，泄漏的goroutines並不會被自動回收，所以確保每一個再也不須要的goroutine能正常退出是重要的。關於無緩存或帶緩存channels之間的選擇，或者是帶緩存channels的容量大小的選擇，均可能影響程序的正確性。無緩存channel更強地保證了每一個發送操做與相應的同步接收操做；可是對於帶緩存channel，這些操做是解耦的。一樣，即便咱們知道將要發送到一個channel的信息的數量上限，建立一個對應容量大小帶緩存channel也是不現實的，由於這要求在執行任何接收操做以前緩存全部已經發送的值。若是未能分配足夠的緩衝將致使程序死鎖。Channel的緩存也可能影響程序的性能。想象一家蛋糕店有三個廚師，一個烘焙，一個上糖衣，還有一個將每一個蛋糕傳遞到它下一個廚師在生產線。在狹小的廚房空間環境，每一個廚師在完成蛋糕後必須等待下一個廚師已經準備好接受它；這相似於在一個無緩存的channel上進行溝通。若是在每一個廚師之間有一個放置一個蛋糕的額外空間，那麼每一個廚師就能夠將一個完成的蛋糕臨時放在那裏而立刻進入下一個蛋糕在製做中；這相似於將channel的緩存隊列的容量設置爲1。只要每一個廚師的平均工做效率相近，那麼其中大部分的傳輸工做將是迅速的，個體之間細小的效率差別將在交接過程當中彌補。若是廚師之間有更大的額外空間——也是就更大容量的緩存隊列——將能夠在不中止生產線的前提下消除更大的效率波動，例如一個廚師能夠短暫地休息，而後在加快遇上進度而不影響其其餘人。另外一方面，若是生產線的前期階段一直快於後續階段，那麼它們之間的緩存在大部分時間都將是滿的。相反，若是後續階段比前期階段更快，那麼它們之間的緩存在大部分時間都將是空的。對於這類場景，額外的緩存並無帶來任何好處。生產線的隱喻對於理解channels和goroutines的工做機制是頗有幫助的。例如，若是第二階段是須要精心製做的複雜操做，一個廚師可能沒法跟上第一個廚師的進度，或者是沒法知足第階段廚師的需求。要解決這個問題，咱們能夠僱傭另外一個廚師來幫助完成第二階段的工做，他執行相同的任務可是獨立工做。這相似於基於相同的channels建立另外一個獨立的goroutine。