协程调度器失活死锁是因唯一协程调用sleep且无i/o事件唤醒，导致进程假死；常见于父子进程协程配置不一致、无超时网络请求、协程泄漏等场景。
协程调度器失活导致的死锁
最典型的死锁不是代码逻辑循环加锁，而是整个协程调度器“睡过去了”——Swoole\Coroutine\System::sleep() 卡住、不报错、CPU 几乎为 0，但进程彻底不动。根本原因是：当前进程里只有一个协程，且它调用了 sleep()，而调度器又没别的 I/O 事件（如 TCP 连接、定时器、channel 操作）来唤醒自己。
常见触发场景：
- 父进程禁用协程（
swoole_async_set(['enable_coroutine' => false])），却在子进程中启用协程并只跑一个无限sleep()循环 -
Swoole\Timer::after()回调里启动子进程，子进程内协程无任何 I/O，仅go(fn() => { while(true) { sleep(1); } }) - 协程里调用未设超时的
curl_exec()或Swoole\Client->connect()，网络卡住后等同于无限阻塞
协程泄漏 + 长时间阻塞引发的隐性死锁
协程本身不释放、不退出，又持续占用资源，会让后续协程无法被调度或新建失败。这不是立即报错的死锁，但会逐步拖垮服务。
典型表现：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
coroutine_num持续上涨，coroutine_peak居高不下，但业务请求响应变慢甚至超时 - 用
swoole-tracker status查看时，发现大量协程状态为sleeping或waiting，但无活跃连接或定时器 - 忘记用
defer关闭数据库连接或 HTTP 客户端，导致连接池耗尽，新协程在co\mysql::connect()处挂起
父子进程间协程配置不一致
协程开关（enable_coroutine）是进程级配置，不能跨进程继承。父进程关了协程，子进程却开了，或者反过来，都会打破调度预期。
关键细节：
-
swoole_async_set()必须在go()或Swoole\Process启动前调用，否则对当前进程无效 - 子进程里重新调用
swoole_async_set()才能生效，父进程的设置不会透传 - 如果子进程只做守护任务（如心跳上报），推荐显式关闭协程：
swoole_async_set(['enable_coroutine' => false]); sleep(1);，避免调度器空转
排查与验证的最小可行动作
别等线上崩了再翻日志。定位是否为调度类死锁，三步就能初步判断：
- 运行
php ./vendor/bin/swoole-tracker status，重点看coroutine_num是否长期为 0 或 1，同时tcp_connections和timer_num是否为 0 - 用
strace -p [pid] -e trace=futex,clone,wait4观察是否卡在futex系统调用上（协程调度底层依赖它） - 临时加一行
go(fn() => { while(true) { \Swoole\Coroutine\System::gethostbyname('www.baidu.com'); break; } });—— 强制引入一个可唤醒的 I/O 事件，看是否恢复调度
真正难处理的不是单个 sleep()，而是多个协程之间因共享状态（如未加锁的全局数组）、channel 使用不当或连接池超时缺失，形成的“非阻塞但永不推进”的状态。这种问题不会立刻暴露，得靠 co::trace() 和持续观察 coroutine_num 波动来揪出来。
