測試告訴我們定時任務沒有執行了，排查相關日誌，只有開始執行，沒有執行結束。估計是什麼地方卡主了。
所以dump分析日誌
先檢查一下載入情況
!eeversion
執行緒卡主了，先看執行緒
!runaway
有兩條執行緒時間挺長的。有一條是我們的排程常駐執行緒。時間成是對的，另一條應該就是卡主的。
先看第一條
~15s
!clrstack
果然這個最長的是排程執行緒看另外一條
另外一條好像是在等socket資料。 看這個函式不是我們這邊負責的，是更底層的人。底層的人反饋說這個時長不一定是卡主了，他是重複利用的，可能是累計起來的
那是不是。因為這條執行緒重複利用。然後累計的時間比較長呢？
第二條跟第三條執行緒時間差的太多了，應該不是。
那麼他真的是卡主了很久嘛？
這裡有一個變數時間。轉換一下格式之後的時間與卡主的資料的時間。是相等的，基本上可以斷定他就是卡在這裡很久很久。
底層的人員反饋，正常情況不會出現卡主的。就算是網路呼叫失敗了一般一分鐘就會爆超時異常。短時間內沒有給出原因。
仔細研究一下這個函式的程式碼。
組裝搜尋條件的時候出錯了。底層返回資料的時候呢就沒有出錯了，因為是邏輯錯誤沒有奔潰。然後出錯了也沒有將IsLastData設定為最後一頁，所以沒有地方跳出迴圈。然後就卡死在這裡了。
至此真想大白，是我們的條件寫的有問題，死迴圈了，而不是最開始定位的Socket 長時間未響應。
關於這種死迴圈取資料的，一定要設定通用的跳出條件，一般情況下可以設定Deadline 設定某一個時間內還沒有執行完的話，跳出，可以設定嘗試重試次數，比如說1000次，還沒有結論，就跳出。然後記錄Debug日誌，方便將來斷言這個地方確實是有問題。然後嘗試修復這個問題。