Swoole协程调度器的工作原理

先说一个核心判断：Swoole 的协程调度器，本质上就是个单线程事件循环上的用户态包工头。 它不依赖操作系统调度，也不另开线程，而是在每个 Worker 进程的主线程里跑一个 `EventLoop`。所有协程都挤在这一条线上排队干活。所谓调度，其实就是这个包工头在 I/O 就绪、定时器触发或者协程主动让出时，从就绪队列里挑一个协程恢复执行。 最容易发生的问题是什么？协程里写个死循环，比如 `while(true) { $i++; }`，整个 Worker 立马卡住，其它协程根本没机会跑。原因很简单：没有 I/O、没有 yield、没有定时器，调度器压根没有插手的时机。 具体来看几个关键点： - 协程只有在遇到 `Co::sleep`、`channel->pop`、`Co::MySQL->query` 这类 hook 化的 I/O 时才会挂起 - `usleep`、`sleep`、以及纯计算循环不会触发调度，想手动让路，得调用 `Co::yield()` 或者改成 `Co::sleep(0)` - Hyperf 这类框架会在请求入口自动创建协程，但如果是 CLI 脚本，调了 `go()` 之后必须补一句 `Co::sleep(0.001)` 或者 `SwooleEvent::wait()`，否则进程一退出，协程直接丢弃 ---

协程切换靠寄存器+栈指针保存，不是线程上下文切换

每次挂起的时候，Swoole 的 C 层只保存当前 CPU 寄存器的状态和栈指针的位置，然后跳转到调度器逻辑；恢复时再把寄存器和栈指针原样载入。整个过程在用户态完成，耗时大约 50ns，远低于线程切换的 1μs。 这里有个容易踩的坑：协程栈默认只有 8KB（可以配置），一旦递归过深或者局部变量太大，就会栈溢出。报错可能是 `Fatal error: Allowed memory size exhausted`，也可能直接静默崩溃，而且 try/catch 根本抓不住。 几点建议： - 不要在协程里递归调用超过百层 - 避免在协程函数内部定义超大的局部数组，比如 `$data = array_fill(0, 100000, 0)` - 可以用 `Co::set(['stack_size' => 2 * 1024 * 1024])` 把栈调大，但别滥用——栈多了，内存压力也跟着上 ---

Hook 是调度器的“眼睛”，没它协程就等于裸奔

调度器本身不干涉代码的执行流，它只响应那些被 hook 了的系统调用。举个例子，`file_get_contents()` 默认仍然是阻塞的，除非你提前调用了 `SwooleRuntime::enableCoroutine(SWOOLE_HOOK_FILE)`，否则它会直接卡死整个 Worker。 一个典型的误用场景：在 `onRequest` 回调里用了 `curl_exec()`，却没有启用 `SWOOLE_HOOK_CURL`。结果并发一上来，所有请求串行排队，QPS 断崖式下跌。 生产环境的建议： - `SWOOLE_HOOK_ALL` 最省心，但存在兼容风险——某些 C 扩展可能绕过 hook - 按需开启更稳妥，比如 `SWOOLE_HOOK_STDIO | SWOOLE_HOOK_CURL | SWOOLE_HOOK_FILE` - 验证 hook 是否生效：在协程里跑 `sleep(1)`，看其他协程是否也被阻塞——如果也阻塞，说明 hook 没启对，或者启得太晚 ---

协程间共享全局状态，隔离的是栈不是内存

每个协程有独立的栈，但 `$_SERVER`、`static $cache`、`global $config` 这些全是进程级共享的。一个协程改了 `$_GET['token']`，下一个协程进来，可能直接读到脏值。 还有一个容易被忽略的点：协程调度依赖底层的 `epoll`/`kqueue`，但这些机制对普通文件（比如 `fopen('/tmp/log.txt')`）并不生效。即使开了 `SWOOLE_HOOK_FILE`，读写本地文件仍然是阻塞的，只不过被模拟成“协程友好”而已，实际并发能力并没有提升。 几个实用的做法： - 跨协程传数据，优先用 `Co::getContext()` 或者闭包捕获 - 缓存类的逻辑慎用 `static`，改用 `Co::getUid()` 做键隔离 - 日志写文件最好走 `Co::writeFile()`，或者投递到 TaskWorker，别在协程里直接 `fwrite()` 说一千道一万，调度器不是万能的，它只能管那些能被它感知到的操作。理解了这一点，协程的很多坑就都能提前绕开了。