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。