【面试点拨】Swoole 底层如何实现异步非阻塞 IO

Swoole 的协程调度，底层依赖的是 epoll（Linux）或 kqueue（macOS/BSD）这类 I/O 多路复用机制，并不是说用了协程就自动异步了。就拿你熟悉的 file_get_contents 来说，它默认还是阻塞的，非得经过 Swoole Runtime::enableCoroutine() 这一层 hook 拦截才能变成协程安全。至于 Co::sleep，它通过定时器 + yield 让出控制权，而 usleep 则是纯粹的同步阻塞，会直接把进程卡死。先记住这几个核心结论，下面逐一展开。

协程调度依赖 epoll/kqueue，不是“自动变异步”

协程本身并不改变 IO 的行为，file_get_contents 该阻塞还是阻塞，除非被 Swoole hook 拦截或者你显式替换了它。Swoole 的异步非阻塞 IO 实际由两层支撑：底层用 epoll（Linux）或 kqueue（macOS/BSD）做事件多路复用，上层靠协程在事件就绪时恢复执行。如果没有就绪通知，协程就挂起；如果没人注册监听，那 IO 永远等不到唤醒。很多人会在这里栽跟头：

• 在 CLI 脚本里调用 Co::readFile 后直接 exit，文件没读完就退出了 —— 因为事件循环根本没跑，epoll_wait 还没开始监听
• 对普通文件（比如 /tmp/log.txt）调用 Co::readFile，性能反而更差 —— 因为 epoll 对 regular file 不生效，Swoole 会退化为线程池来模拟异步，反而增加了上下文切换的开销

Co::sleep 和 usleep 的区别本质是“是否进事件循环”

Co::sleep(1) 是协程安全的等待：它向定时器模块注册一个 1 秒后触发的事件，然后立刻 yield，把控制权交还给调度器；而 usleep(1000000) 是纯同步系统调用，直接进入内核的 nanosleep，期间不返回、不触发任何事件，整个 Worker 进程就被卡死了。什么时候该用哪个？

• 需要让出 CPU 给其他协程处理请求时，必须用 Co::sleep
• 调试中临时加延时，如果误用了 sleep() 或 usleep()，尤其是在 onRequest 回调里，会导致整个服务假死
• Co::sleep(0) 是个小技巧，可以用来强制让出当前时间片，类似 Go 里的 runtime.Gosched()

SwooleRuntime::enableCoroutine() 不是万能开关

启用这个函数后，Swoole 会尝试 hook 常见的 PHP I/O 函数（比如 fread、stream_socket_client），但不可能拦截所有路径。举个典型的例子：某些 C 扩展绕过 PHP 流层直接连到 libc（比如部分 Redis 扩展的 redis->get），或者用 proc_open 启动子进程，这些操作仍然会阻塞。不同参数带来的风险差别很大：

• SwooleRuntime::enableCoroutine(SWOOLE_HOOK_ALL) 覆盖范围最大，但初始化更慢，而且可能破坏那些依赖阻塞行为的旧代码
• 生产环境建议按需启用，比如只开 SWOOLE_HOOK_TCP + SWOOLE_HOOK_SSL，避免影响 file 类操作
• 开启后仍然要检查实际调用链 —— 用 var_dump(stream_get_wrappers()) 可以确认 php:// 等流是否已经被重写

协程间共享全局变量，但 IO 状态不共享

每个协程有独立的栈和寄存器状态，但 $_SERVER、$GLOBALS、静态属性、单例对象仍然是进程级共享的。这意味着你在协程 A 里改了 Config::$timeout = 5，协程 B 下次读到的就是 5 —— 这不是线程安全的。容易踩的坑：

• 在 onRequest 中修改超全局数组（比如 $_GET['token'] = decrypt(...)），后续协程可能读到被污染的值
• 用 Co::getContext() 存请求上下文，但忘记在 defer 中清理，导致内存泄漏
• 以为用了协程就“天然隔离”，结果数据库连接复用逻辑出错，多个协程共用一个未 reset 的 MySQLi 实例

最常被忽略的一点：协程调度器只在 IO 就绪或定时器触发时才有机会切回来。如果你的代码全是 for ($i=0; $i<1000000; $i++) { } 这种纯计算，调度器完全插不进手 —— 它不会主动中断 CPU 密集型逻辑，必须靠 Co::yield() 或者触发 IO 才能让出时间片。