正在開會，突然線上站點線程數破千。然後一羣人現場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函數發生了死鎖的情況，上下文其實也算是相關的。剩下的就只能對比代碼，爲什麼這兩個函數可能發生死鎖了。
