正在開會，突然線上站點線程數破千。然后一群人現場dump分析。

先看一眼線程運行狀態 !eeversion

發現CPU占用并不高，19%，937條線程正在運行。

看看他們都在干什么。 ~* e !clrstack

發現大片內容相似的，并且最后一行是System.Threading.Monitor.Enter，嘗試獲取鎖。很大概率是死鎖了，排查一下是否存在死鎖的情況。

運行 !syncblk 查看當前的鎖的情況

等待數并不是真的等待數，需要（線程數  -1） / 2，至于具體為什么這么算我就不清楚了。將所有的數據相加 正好是等于937。也就是說所有的線程都在運行，所有的線程都得等待鎖，所以肯定出現死鎖了。復制內容出來備用。

從第一個線程 90 開始查。~90s，進入90號線程上下文，然后打印堆棧信息 !clrstack -l

上下文信息中只有這個有值，這個很大概率就是鎖對象的地址。然后去鎖對象列表中查一下

果然是鎖對象，也就是說90號線程應該是在等77號線程。那么77號線程在等什么？切到77號線程，然后打印上下文。

發現也是類似的情況，最后在申請鎖。我們再查一下這個鎖是什么情況。

77號在等70號線程。那么70號線程在等誰？切換上下文到70號線程，然后打印上下文。

發現他也在等一個鎖對象，我們查一下這個鎖對象的擁有者是咋回事。

我們發現 70線程在等77號。那么現在70號跟77號在相互等待，那么這兩個也就死鎖了，其他的相關線程大概率都是跟這個死鎖相關的。既然是這樣，我們分別打印一下77號和70號相關的調用堆棧，就可以對比著代碼查一下，為什么會出現死鎖了。

從這個函數名字上看很大概率是IncrementConnection和CloseOnIdle函數發生了死鎖的情況，上下文其實也算是相關的。剩下的就只能對比代碼，為什么這兩個函數可能發生死鎖了。