正在開會，突然線上站點執行緒數破千，然后一群人現場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函式發生了死鎖的情況，背景關系其實也算是相關的，剩下的就只能對比代碼，為什么這兩個函式可能發生死鎖了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/54755.html
標籤：C#