go自从出生就身带“高并发”的标签，其并发编程就是由groutine实现的，因其消耗资源低，性能高效，开发成本低的特性而被广泛应用到各种场景，例如服务端开发中使用的HTTP服务,在golang net/http包中,每一个被监听到的tcp链接都是由一个groutine去完成处理其上下文的，由此使得其拥有极其优秀的并发量吞吐量
for {
// 监听tcp
rw, e := l.Accept()
if e != nil {
.......
}
tempDelay = 0
c := srv.newConn(rw)
c.setState(c.rwc, StateNew) // before Serve can return
// 启动协程处理上下文
go c.serve(ctx)
}
虽然创建一个groutine占用的内存极小(大约2KB左右，线程通常2M左右)，但是在实际生产环境无限制的开启协程显然是不科学的，比如上图的逻辑，如果来几千万个请求就会开启几千万个groutine,当没有更多内存可用时,go的调度器就会阻塞groutine最终导致内存溢出乃至严重的崩溃，所以本文将通过实现一个简单的协程池，以及剖析几个开源的协程池源码来探讨一下对groutine的并发控制以及多路复用的设计和实现。
一个简单的协程池
主播管理系统中信息不完整的主播找出来然后再到其相对应的直播平台爬取完整信息并补全，当时考虑到每一个主播的数据都要访问一次直播平台所以就用应对每一个主播开启一个groutine去抓取数据，虽然这个业务量还远远远远达不到能造成groutine性能瓶颈的地步，但是心里总是不舒服，于是将其优化成从协程池中控制groutine数量再开启爬虫进行数据抓取。思路其实非常简单，用一个channel当做任务队列，初始化groutine池时确定好并发量，然后以设置好的并发量开启groutine同时读取channel中的任务并执行,
实现
type SimplePool struct {
wg sync.WaitGroup
work chan func() //任务队列
}
func NewSimplePoll(workers int) *SimplePool {
p := &SimplePool{
wg: sync.WaitGroup{},
work: make(chan func()),
}
p.wg.Add(workers)
//根据指定的并发量去读取管道并执行
for i := 0; i < workers; i++ {
go func() {
defer func() {
// 捕获异常 防止waitGroup阻塞
if err := recover(); err != nil {
fmt.Println(err)
p.wg.Done()
}
}()
// 从workChannel中取出任务执行
for fn := range p.work {
fn()
}
p.wg.Done()
}()
}
return p
}
// 添加任务
func (p *SimplePool) Add(fn func()) {
p.work <- fn
}
// 执行
func (p *SimplePool) Run() {
close(p.work)
p.wg.Wait()
}
