windbg 分析线程死锁

📰 来源: 博客园

一、第一步：宏观看整体指标 `!tp`

查看线程池Worker总数、Running/Idle、排队队列；

特征：Running=总线程、Idle=0、队列积压几千 → 大批量线程永久卡死不释放。

初步结论：不是瞬时并发高，是线程泄漏卡死。

看每条：MonitorHeld=占用数、有无等待的Waiter线程

① 有大量等待线程 = 多lock互相争抢，传统Monitor死锁

② 只有占用、无等待线程 = 线程拿着锁卡在业务代码，锁是副产品，不是元凶（你的场景）

~~[0xTID]s;!clrstack 打印单个卡死线程托管堆栈：

栈出现：ManualResetEventSlim.Wait → Task.InternalWait → Task.Wait()
→ 锁定：同步.Wait()阻塞异步任务，上下文死锁。

向上追溯业务类：定位出事方法（ServiceDiscovery、MatrixHelper、HttpModule、Controller）。

命中缓存/连接复用：GetAsync同步执行完毕，返回已完成Task，await不放线程，全链路顺行，正常释放；

真实跨网IO：返回未完成Task，await释放工作线程；IO完成回调要切回AspNetSynchronizationContext，但主线程被.Wait()占死 → 闭环死锁、线程永久滞留。

传统lock死锁：A拿锁1等锁2、B拿锁2等锁1 → 改锁顺序、缩小lock范围；

ASP上下文死锁(本次故障)：同步.Wait()/Result + await无ConfigureAwait(false)
修复二选一：

方案1：全链路改成async/await，删除所有.Wait()；

方案2：所有await xxx.ConfigureAwait(false)，切断回调绑定请求上下文。

!tp看池子满不满，!syncblk辨锁死还是卡死，切线程栈找Wait，缓存决定偶发好坏

🔗 原文链接: 点击阅读原文