Nginx的Event Loop基于epoll等系统级I/O多路复用实现，核心是“同步非阻塞+事件通知”：每次循环执行等待就绪→批量收集→同步调用handler，无用户态任务队列，异步性由连接状态机与事件重注册驱动。
Nginx 的 Event Loop 并不使用传统 JavaScript 那样的单线程异步队列模型，而是基于操作系统提供的高效 I/O 多路复用机制（如 epoll、kqueue、select）实现的事件驱动循环，其核心是“同步非阻塞 + 事件通知”，而非维护一个用户态的待执行回调队列。
Event Loop 的本质是事件分发循环
Nginx 没有类似 Node.js 的 microtask/macrotask 队列，也没有定时器队列或 I/O 完成队列的显式管理。它依赖内核就绪通知（如 epoll_wait 返回就绪 fd 列表），每次循环只做三件事：等待事件就绪 → 批量收集就绪事件 → 依次调用对应 handler（如 accept、recv、send）。所有网络事件都在主线程（worker 进程）中同步处理，无任务排队调度逻辑。
异步操作靠系统调用和状态机驱动
Nginx 将每个连接抽象为一个 connection 结构体，内部维护读写缓冲区、当前处理阶段（如 reading、writing、keepalive）、以及回调函数指针（如 read_handler、write_handler）。当某次 recv() 返回 EAGAIN，它不把请求“入队等待”，而是把该连接保留在事件监听集合中，并在下次 epoll_wait 返回可读时再次尝试 —— 这种“重试+状态推进”就是它的异步行为体现：
- accept 新连接后，立即将其添加到 epoll 监听列表（LT 模式）或等待下次就绪（ET 模式）
- 收到数据后，解析 HTTP 请求头；若未收全，继续监听可读事件，不退出处理流程
- 发送响应时，若 send() 返回 EAGAIN，设置 write event 并等待可写事件，同时挂起当前请求上下文（通过 ngx_http_request_t 的成员保存进度）
定时器等非 I/O 事件由红黑树管理
虽然没有“任务队列”，但 Nginx 仍需处理超时、延迟关闭、定期检查等时间事件。它用一棵红黑树（ngx_event_timer_rbtree）组织所有定时器节点，每次 event loop 迭代前先检查树顶是否到期，批量触发已超时的 timer handler（如关闭空闲连接、清理过期缓存）。这属于事件循环的补充机制，不参与 I/O 调度主路径。
没有用户代码插入点，也无 callback 队列
你不能像在 Node.js 中 setTimeout 或 Promise.then 那样注册任意回调。Nginx 的事件处理完全由模块在初始化时注册 handler 函数指针（如 ngx_http_init_connection），运行时仅按连接状态跳转到预设函数。所有“异步性”都隐藏在连接状态迁移与事件重注册中，开发者只能通过模块开发接口介入，无法手动 push 任务到某个队列。
不复杂但容易忽略：Nginx 的高性能正来自这种极简设计——避免上下文切换、减少内存分配、消除队列竞争。它的“异步”是面向连接的、状态驱动的、系统级的，不是语言层的任务调度。
