記一次Windb死鎖排查

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