Nginx死锁时worker进程无响应但CPU内存正常，可用strace捕获futex阻塞点，再用gdb查看线程栈和锁持有关系，定位第三方模块或配置引发的循环等待锁问题。
当 Nginx 出现请求无响应、worker 进程长时间不处理新连接，但 CPU 和内存又没明显异常时，很可能是死锁——多个线程互相等待对方持有的锁，谁也不放，整个工作流就卡住了。strace 和 gdb 是现场诊断最直接有效的组合：strace 抓住“卡在哪一个系统调用”，gdb 查清“谁在等锁、谁拿着锁、锁之间是否循环等待”。不需要重启、不依赖日志，就能锁定问题线程和锁地址。
用 strace 快速捕获阻塞点
死锁发生时，至少有一个线程会停在 futex 系统调用上（Linux 互斥锁底层机制）。直接对 worker 进程执行：
- strace -p $(pgrep nginx | tail -n1) -e trace=futex -f —— 只跟踪 futex 调用，-f 同时抓子线程，避免漏掉关键线程
- 若看到类似 futex(0x7f234053902c, FUTEX_WAIT_PRIVATE, 2, NULL) 的输出持续不动，说明该线程正等待地址
0x7f234053902c处的锁 - 注意观察是否多个线程反复尝试同一地址的
FUTEX_WAIT_PRIVATE，这是典型争抢同一把锁的信号
用 gdb 查看线程栈与锁持有关系
拿到可疑锁地址后，立即用 gdb 进入进程分析上下文：
- 执行 gdb -p $(pgrep nginx | tail -n1)，进入交互模式
- 运行 thread apply all bt —— 列出所有线程当前调用栈，重点关注停在
pthread_mutex_lock、__lll_lock_wait或自定义模块 lock 函数上的线程 - 对每个可疑线程，切换过去并检查：
(gdb) thread
(gdb) p *(pthread_mutex_t*)0x7f234053902c
查看输出中的__owner字段值，它就是当前持有该锁的线程 ID（LWP ID） - 再查那个
__owner对应的线程栈，看它卡在哪儿——如果它也在等另一把锁，而那把锁又被最初等待的线程持有，就构成闭环死锁
结合配置与模块缩小怀疑范围
死锁往往不出现在 Nginx 核心，而是第三方模块或自定义 handler 中。定位到锁地址和线程栈后，要回溯代码逻辑：
- 用 info sharedlibrary 确认是否加载了非官方模块（如 lua-nginx-module、headers-more-nginx-module），它们的锁实现更易出错
- 查看栈顶函数名，比如频繁出现
ngx_http_lua_*或ngx_http_upstream_keepalive_*，就重点审查对应模块的加锁/解锁配对是否完整 - 检查 nginx.conf 中是否启用了可能引入竞争的配置，例如：
keepalive_requests过高 +upstream keepalive+ 自定义 post_action 模块共用全局锁
验证与临时缓解
确认死锁后，可快速验证并降低影响：
- 向 master 进程发
USR2信号平滑升级，或HUP重载配置（部分场景可释放异常锁状态） - 若确定是某模块导致，临时注释
load_module行或禁用相关指令，观察是否恢复 - 生产环境不建议长期用
master_process off单进程调试，但复现阶段开启它能让 gdb 更稳定地附着到唯一 worker 上
