Nginx超时处理基于全局最小堆定时器与事件循环协同，非独立线程；每个worker独享定时器堆，超时为到期触发动作，与连接绑定且可动态增删，精准低开销。
Nginx 的事件处理核心不是传统单线程 EventLoop（如 Node.js），而是基于操作系统异步 I/O 机制（epoll/kqueue/iocp）构建的多进程协作式事件驱动模型，其“超时请求”处理依赖于统一的定时器管理与事件循环协同，而非在每个连接上独立维护计时逻辑。
定时器不是独立线程，而是事件循环的一部分
Nginx 所有定时器（包括读超时、写超时、keepalive 超时、proxy_timeout 等）都注册到一个全局最小堆（min-heap）中，由主事件循环周期性检查。每次 epoll_wait 返回后，Nginx 不会立即处理就绪事件，而是先调用 ngx_event_expire_timers() 扫描并触发所有已到期的定时器回调。
- 定时器节点结构轻量，只存到期时间（毫秒精度）和回调函数指针
- 最小堆插入/删除复杂度为 O(log n)，适合高频增删（如大量短连接）
- 定时器不唤醒线程，也不依赖信号或额外 fd，完全复用主 event loop 的调度节奏
超时与事件绑定：每个连接的 timer 是可取消的句柄
当建立新连接或发起 upstream 请求时，Nginx 会为其分配一个 ngx_event_t 结构体，并通过 ngx_add_timer() 将其加入全局定时器堆。该 timer 并非“倒计时器”，而是一个“到期执行动作”的声明：
- 例如：客户端读超时，timer 回调是 ngx_http_set_keepalive 或 ngx_http_finalize_request
- 若在超时前收到数据或完成响应，Nginx 会调用 ngx_del_timer() 主动移除该节点，避免误触发
- timer 和连接生命周期解耦：连接关闭时自动清理关联 timer，防止内存泄漏
多进程下定时器无竞争：每个 worker 独立维护自己的 timer heap
Nginx 启动多个 worker 进程，每个 worker 运行独立的 event loop 和独立的定时器堆。这意味着：
- 没有跨进程定时器同步开销，也无需加锁
- 同一请求的所有阶段（accept → read → proxy → write）都在同一个 worker 内完成，timer 始终在本地 heap 中管理
- worker 进程重启时，其 timer heap 自动销毁，不会残留“幽灵超时”
真实超时流程示例：HTTP keepalive 超时
以 keepalive_timeout 65s 为例：
- HTTP 请求处理完毕后，连接进入 keepalive 状态，Nginx 调用 ngx_add_timer(rev, 65000)
- 后续每次收到新请求，都会调用 ngx_del_timer() + ngx_add_timer() 刷新超时时间
- 若 65 秒内无新请求，timer 到期，回调执行 ngx_http_set_keepalive：关闭连接、回收内存、重置连接池
- 整个过程不阻塞事件循环，不影响其他连接的读写调度
这种设计让 Nginx 在高并发下仍能精准、低开销地管理海量连接的生命周期，超时不是“等待”，而是“条件触发”。不复杂但容易忽略的是：它把时间维度完全纳入事件系统，和 fd 事件平权调度。
