阅读Nginx源码应聚焦“单线程+事件驱动”主干，从main切入，定位ngx_worker_process_cycle→ngx_process_events_and_timers→ngx_epoll_process_events→epoll_wait调用链，结合连接池（ngx_connection_t）与事件处理器（ngx_event_t.handler）理解IO多路复用全流程。
阅读Nginx源码的关键在于抓住其“单线程+事件驱动”的主干逻辑，而核心事件循环（ngx_event_process_cycle）与epoll封装（ngx_epoll_module）正是理解这一设计的入口。不必从头逐行读，先定位主循环骨架，再顺藤摸到IO多路复用的具体实现，能快速建立整体认知。
从main函数切入，找到事件循环的起点
Nginx启动后，控制流最终进入ngx_master_process_cycle（master进程）或ngx_single_process_cycle（单进程模式），而worker进程的核心就是ngx_worker_process_cycle。它内部反复调用ngx_process_events_and_timers——这就是事件循环的实质入口。
- 该函数统一调度：检查定时器、处理就绪事件、更新时间缓存，不区分具体IO模型
- 真正分发到epoll的是ngx_epoll_process_events，它在src/event/modules/ngx_epoll_module.c中定义
- 调试时可在ngx_worker_process_cycle加日志，确认是否进入循环，避免卡在配置加载或信号处理阶段
理解ngx_event_t与连接池的绑定关系
Nginx不为每个连接分配独立线程或进程，而是用ngx_connection_t结构体管理连接生命周期，其核心字段read和write都是ngx_event_t*类型。事件就绪时，epoll返回的是文件描述符，Nginx通过fd索引快速查到对应连接结构。
- ngx_cycle_t->connection_n决定连接池大小，所有连接预分配并挂入空闲链表
- ngx_get_connection从空闲链表取连接，ngx_free_connection归还，避免频繁malloc/free
- 每个ngx_event_t的handler字段指向具体处理函数（如ngx_http_wait_request_handler），事件就绪后直接调用，无中间分发层
跟踪epoll系统调用的封装逻辑
Nginx对epoll的使用高度精简：只用epoll_create、epoll_ctl（ADD/MOD/DEL）、epoll_wait三个系统调用，全部封装在ngx_epoll_module.c中。
- ngx_epoll_add_event负责注册读/写事件：设置EPOLLONESHOT防止重复触发，启用EPOLLET（边缘触发）提升性能
- ngx_epoll_del_event在连接关闭或超时时移除fd，避免无效监听
- ngx_epoll_process_events中，epoll_wait返回就绪事件数组，循环调用rev->handler(rev)或wev->handler(wev)，即执行HTTP请求解析或响应发送逻辑
结合调试与日志，验证事件流转路径
光看代码容易迷失，建议配合调试观察实际行为：
- 编译时加--with-debug，在ngx_epoll_process_events开头加ngx_log_debug输出nevents（就绪数）和events[i].data.fd
- 用strace -e trace=epoll_wait,epoll_ctl运行worker进程，确认epoll调用频次与参数是否符合预期
- 发起一个HTTP请求，在ngx_http_wait_request_handler打日志，观察从epoll就绪→读事件触发→HTTP解析的完整链条
掌握这四个环节，就能把Nginx事件模型从抽象概念落到具体函数和数据结构上。后续再深入HTTP模块、负载均衡或共享内存等机制，都有了稳固的底层支撑。
