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