【技术深挖】Swoole 底层是如何封装 epoll 的？

epoll 实例是通过 epoll_create1(EPOLL_CLOEXEC) 创建的。这个系统调用会在内核中为自己初始化一棵红黑树和一个就绪链表，用来统一管理所有监控的文件描述符（fd）。而这里的关键点在于 flags 参数——必须设置为 EPOLL_CLOEXEC，它可不是摆设。

如果不设置这个标记，当通过 fork 创建子进程（比如在 Swoole 中启动 TaskWorker）时，子进程会“继承”这个 epoll fd。一旦父进程退出时没有显式调用 close()，就可能导致 fd 泄漏，甚至后续的 epoll_wait 调用永远阻塞，连接不进不出。很多偶发的连接 hang 住、新连接无法接入的问题，根因就在这里。

验证起来也简单：跑一下 lsof -p $PID | grep epoll，如果发现同一个进程里挂着好几个重复的 epoll fd，那基本上就是 EPOLL_CLOEXEC 缺失闯的祸。

epoll 实例怎么创建？epoll_create1 的 flags 不能随便填

前面提到了 epoll_create1 的第一个关键点。实际上，Swoole 在初始化 Reactor 线程时，这一步是必经之路。它绝不仅仅是“创建”完成那么简单。正如前文所讲，flags 参数直接关系到资源安全和进程模型的稳定性。EPOLL_CLOEXEC 的作用就是在 fork 之后，让子进程不再自动继承该 fd，从根本上避免了上述资源泄漏的问题。

很多人图省事，传个 0 或者干脆忽略这个标记。在单 Worker 进程下，这个问题可能永远不会暴露。但一旦你启用了多进程模型（比如 worker_num > 1），那些看似偶发的连接异常就会频繁出现，排查起来极其头疼。

swoole_event_add 底层干了什么？不是简单注册回调

很多人以为 swoole_event_add 只是把 PHP 的回调函数往某个数组里一塞就完事了。实际情况远比这复杂，它至少干了三件要紧的事：

• 调用 epoll_ctl(EPOLL_CTL_ADD)，将目标 socket fd 正式注册进 epoll 实例的监控队列，并设定好它要监听的事件（EPOLLIN 或 EPOLLOUT）。
• 在用户态维护一个 fd → 回调函数指针 + 上下文结构体的映射表（即 Reactor->event_map），这是连接和回调之间的关键桥梁。
• 为这个 fd 分配或复用 ReactorFd 结构体，用来记录它的读写缓冲区、超时时间，以及是否启用了边缘触发等元信息。

理解了这一点，你就会明白为什么不能在协程里对同一个 fd 反复调用 swoole_event_add。因为它不会自动帮你去重。重复注册会导致内核报错 EEXIST，而 Swoole 默认未必会显式处理这个错误码，最终的后果就是你的回调函数静默丢失——数据来了，但代码毫无反应。

为什么 epoll_wait 阻塞时 CPU 是 0%？这不是“空转”

不少人刚接触时会有个误解：“阻塞 = 白白浪费 CPU 空转”。事实恰恰相反。epoll_wait 在没有事件到达时，是一个真正让出 CPU 的系统调用。内核会把发起调用的线程挂起，交还给调度器，而不是傻傻地轮询。它只在网卡中断、定时器到期或信号到来时，才会被唤醒。

这个行为，是 Swoole Reactor 线程达到数万并发吞吐能力的基石。正因为它“等待”的代价是零，单个 Reactor 线程才有了处理大规模连接的可能性。但这也带来了一个硬约束：所有在 epoll_wait 前后插入的同步、阻塞操作，都会直接拖垮整个事件循环。比如，你在事件回调里执行 file_get_contents 或者一个未经协程化的 Redis get，那么这次阻塞就会被所有连接感知到，每个请求的延迟都会随之飙升。

换句话说：epoll_wait 本身非常轻巧，但它前面和后面的代码，必须保持同样的轻巧。

水平触发（LT）为什么是默认？边缘触发（ET）在 Swoole 里几乎不用

Swoole 的 ReactorEpoll 模块默认使用的是水平触发模式（EPOLLLT）。选择 LT 的原因很务实：它对应用层更友好。只要 fd 处于可读状态，每次 epoll_wait 都会返回通知给你，哪怕你只读了半截数据，下次还会继续通知。而 ET 模式则要求你必须一次把数据读完（直到 recv 返回 EAGAIN），否则内核不会再发出任何新的通知。

这种看似“高效”的机制，在 PHP 协程环境下很容易引发灾难：协程可能在读取数据中途被调度出去，缓冲区里的数据残留下来，却因为 ET 的规则再也不会触发通知，连接就此永久卡死。Swoole 并没有对 ET 模式做专门的协程安全封装，也不推荐手动去切换。除非你完全掌控这个 fd 的整个生命周期，并且不使用任何协程 I/O 函数。

顺带提一点：在 epoll_ctl 注册时没有传入 EPOLLET 标记，那它就一定是 LT。别听有些文档说什么“Swoole 会自动适配”，它不自动，它固定。

从头捋下来，你会发现 epoll 并非什么魔法。它只是把“谁来触发”这件事交给了内核去处理。而真正决定服务稳定性的，是“等来了之后，我们在回调里做了什么”——代码是否协程安全、是否会释放资源、是否处理了各种边界条件。这些，才是压垮高并发服务的最后一根稻草。