goroutine
顺序通信进程 CSP
“顺序通信进程”(communicating sequential processes)或被简称为CSP。CSP是一种现代的并发编程模型，在这种编程模型中值会在不同的运行实例(goroutine)中传递，尽管大多数情况下仍然是被限制在单一实例中。
当一个程序启动时，其主函数即在一个单独的goroutine中运行，我们叫它main goroutine。新的goroutine会用go语句来创建。在语法上，go语句是一个普通的函数或方法调用前加上关键字go。go语句会使其语句中的函数在一个新创建的goroutine中运行。而go语句本身会迅速地完成。
示例 斐波那契数列
计算斐波那契数列+可见的标识来表明程序在正常运行
// animation
func spinner(delay time.Duration) {
for {
for _, r := range `-|/`{
fmt.Printf("
%c", r)
time.Sleep(delay)
}
}
}
// get fibonacci of Nth
func fib(x int) int {
if x < 2 {
return x
}
return fib(x-1) + fib(x-2)
}
func main() {
go spinner(100 * time.Millisecond)
const n = 40
fibN := fib(n) // slow
fmt.Printf("
fibonacci(%d) = %d
", n, fibN)
}
程序分析
main()函数开始运行创建了一个main goroutine；
go spinner创建一个子协程，子协程中存在死循环，所以只有在main goroutine退出时，子协程才会结束。在子协程print或sleep时，子协程会主动交出控制权，然后主协程继续运行；
主协程在计算斐波那契数列也会花费较多的时间，在函数递归调用时，也会交出控制权，让其子他协程运行；
主函数返回时，所有的goroutine都会被直接打断，程序退出。
主协程、子协程交替取得控制权，就形成了并发的效果：一边进行显示输出，一边进行斐波那契计算。
示例 并发的Clock服务
例子是一个顺序执行的时钟服务器，它会每隔一秒钟将当前时间写到客户端。
clock服务器每一个连接都会起一个goroutine。
func main() {
listener, err := net.Listen("tcp", "localhost:8000")
if err != nil {
log.Fatal(err)
}
for {
conn, err := listener.Accept()
if err != nil {
log.Print(err) // e.g., connection aborted
continue
}
handleConn(conn) // handle one connection at a time
}
}
func handleConn(c net.Conn) {
defer c.Close()
for {
_, err := io.WriteString(c, time.Now().Format("15:04:05
"))
if err != nil {
return // e.g., client disconnected
}
time.Sleep(1 * time.Second)
}
}
程序分析
Listen函数创建了一个net.Listener的对象，这个对象会监听一个网络端口上到来的连接，listener对象的Accept方法会直接阻塞，直到 一个新的连接被创建，然后会返回一个net.Conn对象来表示这个连接。
handleConn函数会处理一个完整的客户端连接。在一个for死循环中，将当前的时候用 time.Now()函数得到，然后写到客户端。由于net.Conn实现了io.Writer接口，我们可以直接向 其写入内容。这个死循环会一直执行，直到写入失败。最可能的原因是客户端主动断开连接。这种情况下handleConn函数会用defer调用关闭服务器侧的连接，然后返回到主函数，继续等待下一个连接请求。
这里可以对服务端程序做一点小改动， 使其支持并发: 在handleConn函数调用的地方增加go关键字，让每一次handleConn的调用都 进入一个独立的goroutine。
模拟简单的telnet程序
func main() {
conn, err := net.Dial("tcp", "localhost:8000")
if err != nil {
log.Fatal(err)
}
defer conn.Close()
mustCopy(os.Stdout, conn)
}
func mustCopy(dst io.Writer, src io.Reader) {
if _, err := io.Copy(dst, src); err != nil {
log.Fatal(err)
}
}
程序分析
这个程序会从连接中读取数据，并将读到的内容写到标准输出中，直到遇到end of file的条件 或者发生错误。
回声程序
package main
import (
"bufio"
"fmt"
"log"
"net"
"strings"
"time"
)
//
func echo(c net.Conn, shout string, delay time.Duration) {
fmt.Fprintln(c, strings.ToUpper(shout), time.Now())
time.Sleep(delay)
fmt.Fprintln(c, shout, time.Now())
time.Sleep(delay)
fmt.Fprintln(c, strings.ToLower(shout), time.Now())
}
func handleConn(c net.Conn) {
input := bufio.NewScanner(c)
for input.Scan() {
if input.Text() == "quit" {
c.Close()
} else {
echo(c, input.Text(), 1*time.Second)
}
}
// NOTE: ignoring potential errors from input.Err()
c.Close()
}
func main() {
listen, err := net.Listen("tcp", "localhost:8000")
if err != nil {
log.Fatal(err)
}
for {
conn, err := listen.Accept()
if err != nil {
log.Print(err) // e.g., connection aborted
continue
}
go handleConn(conn)
}
}
Channels
goroutine是Go语音程序的并发机制，channels是goroutine间的通信机制。
一个 channels是一个通信机制，它可以让一个goroutine通过它给另一个goroutine发送值信息。每 个channel都有一个特殊的类型，也就是channels可发送数据的类型。一个可以发送int类型数据的channel一般写为chan int。
创建 channel
ch := make(chan int)
ch = make(chan int) // unbuffered channel
ch = make(chan int, 0) // unbuffered channel
ch = make(chan int, 3) // buffered channel with capacity 3
和map类似，channel也一个对应make创建的底层数据结构的引用。channel的零值也是nil。
一个channel有发送和接受两个主要操作，都是通信行为。一个发送语句将一个值从一个 goroutine通过channel发送到另一个执行接收操作的goroutine。
ch <- x // a send statement
x = <-ch // a receive expression in an assignment statement
<-ch // a receive statement; result is discarded
消息事件
有些消息事件并不携带额外的信息，它仅仅是用作两个goroutine之间的同步，这时候可以用struct{}空结构体作为channels元素的类型。
何时关闭channel
Channel还支持close(ch)操作，用于关闭channel。随后对基于该channel的任何发送操作都将导致panic异常。对一个已经被close过的channel之行接收操作依然可以接受到之前已经成功发送的数据；如果channel中已经没有数据的话讲产生一个零值的数据。
只有当需要告诉接收者goroutine，所有的数据已经全部发送时才需要关闭channel。不管一个channel是否被关闭，当它没有被引用时将会被Go语言的垃圾自动回收器回收。试图重复关闭一个channel将导致panic异常，试图关闭一个nil值的channel也将导致panic异常。关闭一个channels还会触发一个广播机制。
串联的channel和单方向的Channel
Channels也可以用于将多个goroutine连接在一起，一个Channel的输出作为下一个Channel的输入。这种串联的Channels就是所谓的管道（pipeline）。
第一个goroutine是一个计数器，用于生成0、1、2、……形式的整数序列，然后通过channel将该整数序列发送给第二个goroutine；第二个goroutine是一个求平方的程序，对收到的每个整数求平方，然后将平方后的结果通过第二个channel发送给第三个goroutine；第三个goroutine是一个打印程序，打印收到的每个整数。
关闭channel
// Squarer
go func() {
for {
x, ok := <-naturals
if ok != nil {
break // channel was closed and drained
}
squares <- x * x
}
close(squares)
}()
单方向的channel
package main
import "fmt"
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)
}
调用counter(naturals)时，naturals的类型将隐式地从chan int转换成chan<- int。任何双向channel向单向channel变量的赋值操作都将导致该隐式转换。这里并没有反向转换的语法：也就是不能将一个类似chan<- int类型的单向型的channel转换为chan int类型的双向型的channel。
带缓存的Channels
带缓存的Channel内部持有一个元素队列。队列的最大容量是在调用make函数创建channel时通过第二个参数指定的。下面的语句创建了一个可以持有三个字符串元素的带缓存Channel。
ch = make(chan string, 3)
向缓存Channel的发送操作就是向内部缓存队列的尾部插入元素，接收操作则是从队列的头部删除元素。如果内部缓存队列是满的，那么发送操作将阻塞直到因另一个goroutine执行接收操作而释放了新的队列空间。相反，如果channel是空的，接收操作将阻塞直到有另一个goroutine执行发送操作而向队列插入元素。
当channel的缓存队列将不是满的也不是空的，对该channel执行的发送或接收操作都不会发生阻塞。通过这种方式，channel的缓存队列解耦了接收和发送的goroutine。
在某些特殊情况下，程序可能需要知道channel内部缓存的容量，可以用内置的cap函数获取：
fmt.Println(cap(ch)) // "3"
同样，对于内置的len函数，如果传入的是channel，那么将返回channel内部缓存队列中有效元素的个数。因为在并发程序中该信息会随着接收操作而失效，但是它对某些故障诊断和性能优化会有帮助。
fmt.Println(len(ch)) // "2"
Go语言新手有时候会将一个带缓存的channel当作同一个goroutine中的队列使用，虽然语法看似简单，但实际上这是一个错误。Channel和goroutine的调度器机制是紧密相连的，一个发送操作——或许是整个程序——可能会永远阻塞。如果你只是需要一个简单的队列，使用slice就可以了。
示例--返回最快的请求
例子展示了一个使用了带缓存channel的应用。它并发地向三个镜像站点发出请求，三个镜像站点分散在不同的地理位置。它们分别将收到的响应发送到带缓存channel，最后接收者只接收第一个收到的响应，也就是最快的那个响应。因此mirroredQuery函数可能在另外两个响应慢的镜像站点响应之前就返回了结果。（顺便说一下，多个goroutines并发地向同一个channel发送数据，或从同一个channel接收数据都是常见的用法。）
func mirroredQuery() string {
responses := make(chan string, 3)
go func() { responses <- request("asia.gopl.io") }()
go func() { responses <- request("europe.gopl.io") }()
go func() { responses <- request("americas.gopl.io") }()
return <-responses // return the quickest response
}
return之后，没结束的goroutine也会结束吗？
goroutines泄漏
如果我们使用了无缓存的channel，那么两个慢的goroutines将会因为没有人接收而被永远卡住。这种情况，称为goroutines泄漏，这将是一个BUG。和垃圾变量不同，泄漏的goroutines并不会被自动回收，因此确保每个不再需要的goroutine能正常退出是重要的。
channel的选择--缓存和不带缓存
关于无缓存或带缓存channels之间的选择，或者是带缓存channels的容量大小的选择，都可能影响程序的正确性。无缓存channel更强地保证了每个发送操作与相应的同步接收操作；但是对于带缓存channel，这些操作是解耦的。同样，即使我们知道将要发送到一个channel的信息的数量上限，创建一个对应容量大小的带缓存channel也是不现实的，因为这要求在执行任何接收操作之前缓存所有已经发送的值。如果未能分配足够的缓冲将导致程序死锁。
蛋糕生产线的比喻
Channel的缓存也可能影响程序的性能。想象一家蛋糕店有三个厨师，一个烘焙，一个上糖衣，还有一个将每个蛋糕传递到它下一个厨师在生产线。在狭小的厨房空间环境，每个厨师在完成蛋糕后必须等待下一个厨师已经准备好接受它；这类似于在一个无缓存的channel上进行沟通。
如果在每个厨师之间有一个放置一个蛋糕的额外空间，那么每个厨师就可以将一个完成的蛋糕临时放在那里而马上进入下一个蛋糕在制作中；这类似于将channel的缓存队列的容量设置为1。只要每个厨师的平均工作效率相近，那么其中大部分的传输工作将是迅速的，个体之间细小的效率差异将在交接过程中弥补。如果厨师之间有更大的额外空间——也是就更大容量的缓存队列——将可以在不停止生产线的前提下消除更大的效率波动，例如一个厨师可以短暂地休息，然后再加快赶上进度而不影响其他人。
另一方面，如果生产线的前期阶段一直快于后续阶段，那么它们之间的缓存在大部分时间都将是满的。相反，如果后续阶段比前期阶段更快，那么它们之间的缓存在大部分时间都将是空的。对于这类场景，额外的缓存并没有带来任何好处。
生产线的隐喻对于理解channels和goroutines的工作机制是很有帮助的。例如，如果第二阶段是需要精心制作的复杂操作，一个厨师可能无法跟上第一个厨师的进度，或者是无法满足第三阶段厨师的需求。要解决这个问题，我们可以雇佣另一个厨师来帮助完成第二阶段的工作，他执行相同的任务但是独立工作。这类似于基于相同的channels创建另一个独立的goroutine。