@
Nanosk go 协程池的几种主要实现方式：
1. 早期最简单的 chan 方式，多数实现会支持常驻协程，性能一般，但是简单易用。
2. gent 作者的 ants ，用 cond_t 实现，好像也是支持常驻协程。实现复杂，号称性能吊打其他协程池，但我和一些朋友实测并没有发现性能优势，而且实现的过于复杂，可能只是跟其他那些用 chan 的实现方式对比有优势。
3. 字节家的 gopool ，链表作为任务队列，如果当前执行任务的协程数量小于协程池 size ，则直接创建新的协程去执行任务，否则就等待当前正在执行任务的协程 for 循环挨个取任务执行。这种相较于 1 、2 性能是最好的，实现也简单。但有个缺点，生产持续大于消费速度时，队列一直增长，没有对上游自动反馈和限流的机制。
4. nbio/taskpool 的实现方式，与 3 中的字节家 gopool 类似、区别在于用 chan 做队列。
1 、2 两种都是支持常驻协程。但是，大概 golang 1.18 以后，runtime 自己有 goroutine 复用之类的，所以 go func()开销很小，比 1 、2 用 chan 、cond_t 那些实现方式性能更好，而且省掉了常驻协程。常见的 rpc 框架中、每个 Call 的处理默认都是 go func()，压测每秒几十万次 go func()都没什么压力，因为任务快速、同时并发存在的协程数量不多。协程池本身就限制了协程池 size ，所以每次 go func()就可以了，根本没必要使用常驻协程等待任务到来、新任务用 chan 传递反倒浪费性能甚至大于 go func()的开销。
3 、4 两种，多数时候设置的协程池 size 是 1w 以上，多数的业务，整个系统请求下有资源可能阻塞才会让协程池的协程短暂驻留，但通常 1w 这种级别也足够用了，否则下有资源也扛不住太高的并发量级，而且下有通常也是自带池限制的、比如 http.Client 和 sql.DB 的连接池。
而且多数情况是协程池 size 跑不满的，所以 3 、4 两种通常都是简单的原子判断协程池 size 、然后 go func()去执行、性能最好也最简单。
所以 1 、2 的那些库我是不推荐的。
我自己在 nbio 中使用自己的这种实现，因为 nbio 的主要设计目标就是资源控制、避免严重的 STW 和 OOM ，所以这种上下游之间的自动反馈和限流很有用。
如果你的业务上游自己有对协程池的限流，则直接使用字节家的就好，否则建议用 nbio 的这种。
字节家的：
https://github.com/bytedance/gopkg/tree/main/util/gopoolnbio 的（实现的很简单，百十来行有效代码，如果需要定制之类的、自己拷贝过去随便修改即可，feel free ）：
https://github.com/lesismal/nbio/blob/master/taskpool/taskpool.go
lesismal
Select Language