@kuanat

> 也许我这样说有点暴论，但我认为，一个承载能力为 N 的系统和一个承载能力在 0~N 之间变动的系统在生产环境是没有区别的，而前者的复杂度耕地，可维护性更高。

看上去有道理, 但这就和 javaer 说"堆机器就行了"是一个道理, 都属于看上去对, 但只适用于普通场景

一旦放大到规模效应, 海量的业务, 这差别就大了, 别人努力去搞动态的方向上是对的, 如果实现的方式能达到较优解就更好了

@kuanat

> 反倒需要我经常强调动态可变实现带来的不可预测性才是大忌。

接#28, go func()的成本很低, 如果稳定性有问题, 那 runtime 也不稳定了, 预热创建也会不稳定. 较早版本的 go 可能没这么优秀, 1.15 还是 1.18 哪个版本之后来着, runtime go func()和协程复用已经足够优秀了, 所以你不必太担忧这个问题

> 即便是一个理想的动态实现，使用的时候还是会根据硬件、网络实测一个并发上限并一直沿用下去，那这和写一个固定的实现没有什么区别

预热创建和动态创建销毁, 在软硬件的常驻占用和能源消耗硬件持久健康上还是有区别的, 规模越大, 成本效益越大


引起 golang 不稳定的更多是过载, 海量连接之类的导致的协程数量, 对象数量, 对应的内存和调度和 gc 压力, 对应的 oom 和 stw 问题. 为了搞这些, 我搞了这个:
https://github.com/lesismal/nbio
1m websocket connections on 4core cpu ubuntu vm, 1k payload echo test, server costs 1g mem, 能跑 10w qps:
https://github.com/lesismal/go-websocket-benchmark?tab=readme-ov-file#1m-connections-1k-payload-benchmark-for-nbiogreatws

@kuanat #24

> 一次性预热分配好常驻就可以了

没必要, runtime 复用协程的性能是足够的, 我们做 RPC 框架的压测, 每个 RPC Call 都是 go func() 一个协程处理, 处理完后就退出了, 每秒几十万 Call, 也就是每秒几十万次 go func(), 毫无压力. 可以参考鸟窝老师的文章, 这里的 RPC 框架的测试都是每个 RPC Call 都 go func() 的, go func() 成本很低的:
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

所以, 预热分配除了浪费常驻内存, 额外的 chan 或者 cond_t 反而可能比直接 go func()还慢, 真的没什么必要, 限制协程数量+队列+go func() 可能才是更优解

@kuanat #14 基本上就是有需要限制协程数量的地方需要这个, 比如海量并发 epoll+逻辑协程池, 比如不同业务模块的协程池(例如常见的连接池)

没有限制协程数量的需求的场景, 硬要用协程池代替 go func 的基本都是画蛇添足

lua 成熟的实现应该挺多的，golang 里这个就可以，拿去用你的语言调用就可以了：
https://github.com/go-redis/redis_rate/blob/v10/lua.go

扫了一眼 OP 的这个协程池，练手可以，但建议还是参考下 #9 吧

另外，协程池做性能测试需要考虑不同的业务场景特点，比如：
1. 任务的消耗类型和消耗时长
2. 协程池 size 、并发度

不同的测试参数，不同的协程池的压测数据可能各有快慢，要考虑实际的业务特点，用某个测试参数就得出某个或者某些协程池最快的结论是不太准确的。

一些库的作者自己宣称自己的库性能第一，但结论并不准确。
比如某些网络库号称自己 tcp 比标准库快、但其实可能是他的压测例子里自己的库的 write buffer size 大、标准库的 write buffer size 小，导致标准库浪费更多 syscall ，然后得出比标准库快的结论。
比如某些网络库号称自己的 http 拿过“天梯”第一，但其实他的压测用例只是实现了简单的 http 头和尾的判断，根本没法处理完整 http 协议或功能，拿去对比别人完整功能的框架，然后得到个第一的跑分，但作者自己知道、天体跑分仓库的 owner 也知道。但这种结果拿来给自己的仓库做宣传并且没有明确说明，就有点误导用户了

测试方法不严谨或者测试参数不全面、不同框架的配置、测试参数不统一，就不能得出准确的结论，用户们应该自己去多看几眼、多自己跑代码测试一下，别轻信仓库官方自己声明的数据、不管官方是大厂还是个人开发者、也不管仓库主要作者是中国还是外国背景（因为都可能有类似问题）。

按照协程是否常驻，目前主要分两大类：

### 一、idle 协程常驻
1. ants ，好象是常驻协程 cond_t 方式实现
2. 常驻协程+chan 的多种方式

goroutine 比较轻量，runtime 自己就有协程复用相关的，所以每次 go 创建新协程其实成本不大，所以常驻协程未必就是好事情，反倒是常驻协程额外的 chan 或者 cond_t 会有相对一点性能损失以及常驻的内存开销
我和一些小伙伴对各种协程池做压测，想比喻非常驻协程的方案，ants 并不具有性能优势

### 二、idle 协程不常驻
1. 字节的 gopool 这种：协程数量控制+任务队列的方式。当前协程数量没有达到最大则新任务直接创建协程执行，每个协程执行完当前也都会检查队列里是否有新的任务、如果有继续取出任务执行、否则协程退出。如果当前协程数量达到最大值就加入队列等待被执行。字节 gopool 的队列用的 list ，其他实现也有复用 slice 的

goppol 避免了常驻协程的内存开销，协程用完就归还给 runtime ，清爽轻量，没有额外的 chan 、cond_t 之类的操作的损失、性能好，但缺点是 gopool 这种实现的队列，再并发任务数量巨大、任务执行较慢时，会导致队列 size 爆炸性增长，没办法像 chan 那样自然限流去实现系统平衡

2. nbio 的协程池，协类似 gopool 但队列替换成了一个常驻协程+chan 。任务协程数量没达到最大值时新任务直接创建新协程执行、否则加到 chan 队列里，只有一个常驻协程+chan 做队列可以实现自然限流（ chan 满了阻塞、自动反馈给调用方）。任务协程用完就还给 runtime ，1 个常驻协程成本也很低，也弥补了 gopool 那种限流缺陷，比较平衡。

@Hookery 评论符合 ID, sixsixsix

贤者时间是这样的

学学怎么"扣"吧

先把价格打下来

64G 1T 起步, 可以战 5 年
16G/512G 明年又想换 ( 明年是指 2 个月后, 甚至更短时间后 )

@lasuar Can't agree more!

如果不用 orm, 可以试试我这个 github.com/lesismal/sqlw

拉满更香

OP 可以好好修行下技术跳槽到好点的公司, 然后就可以较大程度避免这种队友了

加油兄弟