nginx worker process 通过预分配固定数量的连接槽位实现连接池管理，启动时一次性分配 ngx_connection_t 结构体并挂入空闲链表，连接获取与归还仅重置字段、不触发 malloc/free；connections[]、read_events[]、write_events[] 三数组下标严格一一对应，实现零查找开销的事件定位；连接可用性受 worker_rlimit_nofile 和内存池双重约束。
Nginx 的 Worker Process 并不动态创建或销毁连接对象，而是通过预分配、复用的连接池统一管理连接状态，核心是 连接槽位复用 + 事件绑定 + 内存池协同，不是为每个 TCP 连接 malloc 一个新结构。
连接池初始化：启动即预分配固定数量槽位
每个 worker 进程在启动时，就根据 worker_connections 值（如 65535）一次性分配好对应数量的 ngx_connection_t 结构体，全部挂入空闲链表。这些结构体不随 socket 生效/关闭而增减，只在 worker 退出时统一释放。
- 默认大小为 512，生产环境必须调大（如 4096 或 65535），否则成为并发瓶颈
- 每个
ngx_connection_t在 64 位系统中约占用 232 字节，需结合内存预算权衡设置 - 该数组同时服务于客户端连接和上游代理连接；反向代理场景下，1 个客户端请求可能消耗 2 个连接槽位（client + upstream）
连接获取与归还：无 malloc/free 的高效复用
新连接到来时，worker 调用 ngx_get_connection() 从空闲链表头部取一个已分配好的 ngx_connection_t，仅重置关键字段（如 fd、read/write 事件指针、数据缓冲区）；连接关闭后，调用 ngx_free_connection() 将其清空并放回空闲链表，全程不触发堆内存操作。
- socket 文件描述符（fd）与
ngx_connection_t槽位是临时绑定关系，不是一对一持久映射 - keepalive 连接复用时，同一
ngx_connection_t可多次服务不同 HTTP 请求，仅重置请求上下文 - 若空闲链表为空，新连接会被直接拒绝（返回 503），不会降级为阻塞等待
连接与事件强绑定：索引对齐，零查找开销
worker 进程内有三个等长数组：connections[]、read_events[]、write_events[]，长度均为 worker_connections。三者通过下标严格一一对应——第 i 个连接槽位的读/写事件，必定是第 i 个读事件结构和第 i 个写事件结构。
- epoll_wait 返回就绪事件后，Nginx 直接用事件中的 data.ptr 或 data.fd 反查索引，毫秒级定位到对应
ngx_connection_t - 每个连接固定绑定一对事件结构（共约 192 字节），总内存 =
worker_connections × (232 + 192)字节 - 这种设计彻底避免哈希或红黑树查找，是支撑百万并发的关键底层机制
状态维护依赖外部约束：文件描述符与内存池联动
ngx_connection_t 本身不管理 socket 生命周期，其可用性受两个硬限制制约：
-
worker_rlimit_nofile必须 ≥worker_connections，否则系统层无法分配足够 fd，导致 accept 失败 - 连接使用的内存缓冲区（如
recv_buffer）来自 worker 级内存池（ngx_pool_t），而非连接结构体内部；连接释放时缓冲区不立即回收，由内存池批量管理 - 当配置了
accept_mutex off（高并发推荐），多个 worker 可能同时 accept，但连接槽位仍由各自本地池独立提供，无跨进程竞争
