协程饥饿是某个就绪协程长期不被调度执行，而死锁是所有协程互相等待卡死，活锁是协程忙等无进展；饥饿表现为协程id存在但执行停滞、无系统调用、堆栈不动。
协程饥饿（Starvation）在 Swoole 中不是报错，也不会触发异常，它表现为某些协程长期得不到调度执行——你写好了 go()，但里面的逻辑就是“迟迟不跑”，或者跑得极慢、间隔极大。这不是代码没生效，而是调度层面被压制了。
协程饥饿和死锁、活锁的根本区别在哪
死锁是所有协程卡在互相等待；活锁是协程在忙等、反复让步但毫无进展；而饥饿是某个协程“被遗忘”：它就绪、可运行、没阻塞，但调度器就是不选它。
- 死锁：
Co::stats()['coroutine_num']会稳定不变，Co::list()返回的协程 ID 长期卡住，堆栈停在锁等待点（如Channel->push()或Mutex->lock()） - 活锁：CPU 占用高，
Co::stats()['coroutine_num']可能波动剧烈，日志里能看到高频重试或自旋（比如反复Channel->pop(0)失败后立刻重试） - 饥饿：
Co::list()能看到那个协程 ID 一直在，但它的执行时间戳几乎不动；strace -p $PID也看不到它触发任何系统调用——它就像排队时永远轮不到的那个人
什么场景下 Swoole 会饿死协程
饥饿通常不是 Swoole 的 Bug，而是调度策略与使用方式冲突的结果。最常见于以下三类情况：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 无限循环中未主动让出 CPU：比如
while (true) { /* 纯计算 */ }，没调用Co::sleep(0)或Co::usleep(1)，协程霸占调度权，其他协程无法切入 - Channel 容量为 1 且生产者 push 过快：消费者来不及 pop，后续 push 阻塞在 Channel 上，而该协程又没设超时，导致它卡住并间接拖慢整个调度队列
- 错误复用全局资源：例如多个协程共用同一个
Swoole\Coroutine\MySQL实例（非连接池），一个协程长时间占用连接，其他协程只能排队等，等不到就“饿”着
怎么确认是不是协程饥饿而不是其他问题
别只看日志或响应时间。饥饿的典型信号是「有协程活着，但行为停滞」——你需要交叉验证状态：
- 用
Co::list()拿到目标协程 ID（比如12345），再用co::getBackTrace(12345)查看它当前停在哪一行。如果停在纯计算循环里，大概率是饥饿 - 对比
Co::stats()['coroutine_num']和实际业务逻辑应创建的协程数。若前者远小于后者，说明很多go()根本没被调度起来 - 启用 Swoole 调度统计：
swoole.enable_coroutine=1+swoole.display_errors=1，然后观察错误日志是否出现WARNING swManager_loop: coroutine stack overflow类提示——这常伴随调度失衡
饥饿最难调试的地方在于：它不报错、不崩溃、甚至内存和 CPU 看起来都正常。你得主动去看协程有没有“呼吸”，而不是等它喊疼。
