Python 的 async 协程当前真的能跑在生产环境吗？

@LostPrayers #38 请问是遇到什么问题才换的 golang

@cj323 #44 感谢，研究下 gevent

用了 asyncio ，就得有这个觉悟，整个团队的技术水平和规范都得跟上。简单说，Python 的 asyncio 就是个残废。需要你自己手动挡换挡，一不留神就熄火。Go 的 goroutine 才是真正的自动挡。

@clemente #58 怎么说？

按你的附言所说的情况
如那个语句真的是能占满 cpu ，那我觉得不让也行啊。干哪个活不是干啊，何必厚此薄彼

很难想象这是 2025 年的问题

@julyclyde #65 如果对响应时间敏感的服务呢？

@GetMoneyMan #63 很形象了

@julyclyde #65 如果是纯多线程，系统会自动切线程执行，不会让一个线程把整个系统全阻塞住

不过看起来 python 的协程会

@wudanyang 都把 cpu 占满了还有脸说时间敏感？
扩容啊！！

@julyclyde #70 一种是 cpu 时间片占满不释放，导致其他请求延迟，导致并发升高，从而导致整个服务崩掉。
还有一种是 cpu 时间片一段时间后被抢占，其他请求虽然有一些影响但是还是会比较快返回。

看了一下 rust 的 tokio 协程实现。
虽然也是协作式调度，但其原生支持 flavor = "multi_thread" 多线程调度器，支持工作窃取。
还有调度预算机制，用于防止单个任务长期占用线程，从而造成其他任务饿死或延迟。
tokio 不能避免阻塞，只是更加安全一些。

早期 Go 1.14 之前的调度器相当于 协作式调度，协程只在特定时机（如函数调用、通道操作、`time.Sleep`等）主动让出 CPU 。死循环中若没有这些操作，调度器无法抢占执行权。
Go 1.14 之后调度器引入了基于信号抢占 ，即使协程执行死循环，操作系统会向运行该协程的线程发送信号抢占执行权。

@wudanyang 用协程也是要多进程部署的，单个进程只能用到一个 cpu ；单个进程里的协程占者 cpu 不放，不同进程还是会抢占啊