nginx 无死锁，因其采用单线程事件驱动状态机：每个连接独享私有状态与内存上下文，依赖异步i/o与epoll，不使用锁机制；所谓“卡住”实为上游超时、缓冲区满或阻塞调用等外部问题。
Nginx 本身不使用传统多线程模型，也不存在“请求处理死锁”这一说法——它靠事件驱动状态机实现非阻塞处理，天然规避了线程间因锁竞争导致的死锁问题。
状态机如何替代锁机制
Nginx worker 进程对每个连接只维护一个轻量级状态机，整个请求生命周期（读请求头、读请求体、转发、收响应、写响应）被拆解为多个明确状态。每个状态只做一件事，完成后立即转入下一状态或等待 I/O 事件，不持有任何跨请求的共享资源锁。
- 所有连接独立运行在各自的内存上下文中，无共享连接数据结构
- 没有“等待对方释放锁”的逻辑，只有“等待内核通知可读/可写”
- 即使某个请求卡在 upstream 等待后端响应，也不会阻塞其他连接的状态流转
关键设计保障无死锁行为
状态机的有效性依赖三方面底层约束：
- 单线程事件循环：每个 worker 是单线程运行，避免线程切换与竞态；所有回调都在同一执行流中调度
- 零共享连接状态：连接间的 buffer、headers、ctx 等全部私有，无需互斥访问
- 异步 I/O 驱动：read/write 操作永不阻塞，失败时立即返回并注册下次 epoll 事件，不进入等待队列
什么情况下看似“卡住”但不是死锁
若观察到请求长时间无响应，常见原因与状态机无关，而是外部依赖或配置问题：
- upstream 后端超时未返回，状态机停留在“waiting for upstream”状态，属正常等待
- proxy_buffering 关闭 + 大响应体，导致 write 缓冲区满、反复触发 epoll wait
- 第三方模块（如 Lua）在 handler 中执行同步阻塞调用（如 os.execute），强行中断状态流转
- 磁盘满或日志目录不可写，使 ngx_log_error 内部 write 失败并重试，拖慢整个事件循环
验证状态机是否健康
可通过以下方式确认系统处于预期的非阻塞状态：
- 用 strace -p $(pgrep nginx) -e trace=epoll_wait,read,write 观察是否持续收到 epoll_wait 返回，且 read/write 调用频次与流量匹配
- 检查 nginx -s status（需启用 stub_status）输出中的 Active connections 和 Reading/Writing/Waiting 数值是否动态变化
- 对比 netstat -antp | grep :80 | wc -l 与 worker_connections 设置，确认连接未堆积在 SYN_RECV 或 CLOSE_WAIT
