goroutine和channel是Go语言非常棒的特色，它们提供了一种非常轻便易用的并发能力。但是当您的应用进程中有很多goroutine的时候，如何在主流程中等待所有的goroutine 退出呢？
创新互联主要从事成都网站设计、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务伊川,十余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18980820575
1 通过Channel传递退出信号
Go的一大设计哲学就是：通过Channel共享数据，而不是通过共享内存共享数据。主流程可以通过channel向任何goroutine发送停止信号，就像下面这样：
func run(done chan int) {
for {
select {
case -done:
fmt.Println("exiting...")
done - 1
break
default:
}
time.Sleep(time.Second * 1)
fmt.Println("do something")
}
}
go语言的channel。根据查询相关资料信息显示，go语言的channel适合不共享内存编译。编译模式是指如何在内存中放置程序代码及数据，如何分配堆栈，并确认占用的内存大小及如何存取。
Go的CSP并发模型
Go实现了两种并发形式。第一种是大家普遍认知的：多线程共享内存。其实就是Java或者C++等语言中的多线程开发。另外一种是Go语言特有的，也是Go语言推荐的：CSP（communicating sequential processes）并发模型。
CSP 是 Communicating Sequential Process 的简称，中文可以叫做通信顺序进程，是一种并发编程模型，由 Tony Hoare 于 1977 年提出。简单来说，CSP 模型由并发执行的实体（线程或者进程）所组成，实体之间通过发送消息进行通信，这里发送消息时使用的就是通道，或者叫 channel。CSP 模型的关键是关注 channel，而不关注发送消息的实体。 Go 语言实现了 CSP 部分理论 。
“ 不要以共享内存的方式来通信，相反， 要通过通信来共享内存。”
Go的CSP并发模型，是通过 goroutine和channel 来实现的。
goroutine 是Go语言中并发的执行单位。其实就是协程。
channel是Go语言中各个并发结构体(goroutine)之前的通信机制。 通俗的讲，就是各个goroutine之间通信的”管道“，有点类似于Linux中的管道。
Channel
Goroutine
本文是对 Gopher 2017 中一个非常好的 Talk�: [Understanding Channel](GopherCon 2017: Kavya Joshi - Understanding Channels) 的学习笔记，希望能够通过对 channel 的关键特性的理解，进一步掌握其用法细节以及 Golang 语言设计哲学的管窥蠡测。
channel 是可以让一个 goroutine 发送特定值到另一个 gouroutine 的通信机制。
原生的 channel 是没有缓存的(unbuffered channel)，可以用于 goroutine 之间实现同步。
关闭后不能再写入，可以读取直到 channel 中再没有数据，并返回元素类型的零值。
gopl/ch3/netcat3
首先从 channel 是怎么被创建的开始:
在 heap 上分配一个 hchan 类型的对象，并将其初始化，然后返回一个指向这个 hchan 对象的指针。
理解了 channel 的数据结构实现，现在转到 channel 的两个最基本方法: sends 和 receivces ，看一下以上的特性是如何体现在 sends 和 receives 中的:
假设发送方先启动，执行 ch - task0 :
如此为 channel 带来了 goroutine-safe 的特性。
在这样的模型里， sender goroutine - channel - receiver goroutine 之间， hchan 是唯一的共享内存，而这个唯一的共享内存又通过 mutex 来确保 goroutine-safe ，所有在队列中的内容都只是副本。
这便是著名的 golang 并发原则的体现:
发送方 goroutine 会阻塞，暂停，并在收到 receive 后才恢复。
goroutine 是一种 用户态线程 , 由 Go runtime 创建并管理，而不是操作系统，比起操作系统线程来说，goroutine更加轻量。
Go runtime scheduler 负责将 goroutine 调度到操作系统线程上。
runtime scheduler 怎么将 goroutine 调度到操作系统线程上？
当阻塞发生时，一次 goroutine 上下文切换的全过程:
然而，被阻塞的 goroutine 怎么恢复过来？
阻塞发生时，调用 runtime sheduler 执行 gopark 之前，G1 会创建一个 sudog ，并将它存放在 hchan 的 sendq 中。 sudog 中便记录了即将被阻塞的 goroutine G1 ，以及它要发送的数据元素 task4 等等。
接收方 将通过这个 sudog 来恢复 G1
接收方 G2 接收数据, 并发出一个 receivce ，将 G1 置为 runnable :
同样的, 接收方 G2 会被阻塞，G2 会创建 sudoq ，存放在 recvq ，基本过程和发送方阻塞一样。
不同的是，发送方 G1如何恢复接收方 G2，这是一个非常神奇的实现。
理论上可以将 task 入队，然后恢复 G2, 但恢复 G2后，G2会做什么呢？
G2会将队列中的 task 复制出来，放到自己的 memory 中，基于这个思路，G1在这个时候，直接将 task 写到 G2的 stack memory 中！
这是违反常规的操作，理论上 goroutine 之间的 stack 是相互独立的，只有在运行时可以执行这样的操作。
这么做纯粹是出于性能优化的考虑，原来的步骤是：
优化后，相当于减少了 G2 获取锁并且执行 memcopy 的性能消耗。
channel 设计背后的思想可以理解为 simplicity 和 performance 之间权衡抉择，具体如下：
queue with a lock prefered to lock-free implementation:
比起完全 lock-free 的实现，使用锁的队列实现更简单，容易实现
没有，union是很好的东西，但是go恐怕不会去支持。
毕竟union这个东西主要还是用于不降低速度下的节约内存，为此增加的复杂度。
go语言
不会支持的。
