nginx事件循环是worker进程内同步执行的单线程主循环，通过epoll_wait等待fd就绪、搬运事件至队列、同步调用handler实现高效i/o调度，按需注册事件、无中断回调、零线程切换开销。
Nginx 的事件循环不是靠多线程或回调中断驱动的“黑盒”，而是一个由 worker 进程自主控制、同步执行的主循环，核心目标是用单线程高效调度成千上万个非阻塞连接。
事件循环运行在 worker 进程内，不依赖线程切换
每个 worker 是一个独立的 Unix 进程，内部只有单一执行流。它不为每个连接创建线程，而是持续运行一个 while 循环：
- 调用 epoll_wait()（Linux）或类似系统调用，等待内核通知哪些 fd 就绪
- 超时时间由定时器系统动态决定，兼顾延迟与节能
- 返回后不立刻处理业务，只把就绪事件“搬运”进内部就绪队列
- 接着遍历该队列，依次同步调用每个事件绑定的 handler 函数
事件注册是按需、分阶段完成的
handler 不是一次性全局注册，而是在连接生命周期的关键节点动态挂载：
- 监听 socket 在 worker 初始化时注册读事件，handler 设为 ngx_event_accept，专用于接受新连接
- accept 到新连接后，为其读事件绑定 HTTP 请求解析函数（如 ngx_http_process_request_line）
- 需要发响应时，才为写事件注册 handler（如 ngx_http_writer），并可能触发 epoll_ctl(EPOLL_CTL_MOD)
- 所有注册都通过 ngx_event_t 结构体完成，其中 handler 存函数指针，data 存连接或请求指针，确保回调时有上下文
事件分发和回调都是同步可控的
没有异步回调、没有中断、不引入额外调度开销：
- 分发阶段只做“翻译”：把内核返回的 epoll_event 转为 Nginx 内部的 ngx_event_t *，填入就绪队列
- 回调阶段直接执行 ev->handler(ev)，完全同步；当前 worker 会阻塞在此调用，直到 handler 返回
- handler 内部决定是否继续注册新事件（比如读完 header 后注册 body 读事件）、是否关闭连接
- 定时器、清理任务也统一纳入这个循环，共用同一套调度逻辑
这种设计让 Nginx 能支撑万级连接的关键原因
它绕开了传统多线程模型的典型瓶颈：
- 每个空闲连接仅占用约 2–4 KB 内存，不含线程栈等开销
- 无上下文切换：10 万连接 ≈ 10 万个 fd，但只需 4–8 个 worker 进程
- 无锁路径为主：worker 间不共享连接状态，业务处理几乎不涉及锁
- 真正并发靠的是事件触发的协作，不是并行执行；CPU 始终可用，不会因某次 I/O 卡住整个进程
