测试告诉我们定时任务没有执行了，排查相关日志，只有开始执行，没有执行结束。估计是什么地方卡主了。
所以dump分析日志
先检查一下加载情况
!eeversion
线程卡主了，先看线程
!runaway
有两条线程时间挺长的。有一条是我们的调度常驻线程。时间成是对的，另一条应该就是卡主的。
先看第一条
~15s
!clrstack
果然这个最长的是调度线程看另外一条
另外一条好像是在等socket数据。 看这个函数不是我们这边负责的，是更底层的人。底层的人反馈说这个时长不一定是卡主了，他是重复利用的，可能是累计起来的
那是不是。因为这条线程重复利用。然后累计的时间比较长呢？
第二条跟第三条线程时间差的太多了，应该不是。
那么他真的是卡主了很久嘛？
这里有一个变量时间。转换一下格式之后的时间与卡主的数据的时间。是相等的，基本上可以断定他就是卡在这里很久很久。
底层的人员反馈，正常情况不会出现卡主的。就算是网络调用失败了一般一分钟就会爆超时异常。短时间内没有给出原因。
仔细研究一下这个函数的代码。
组装搜索条件的时候出错了。底层返回数据的时候呢就没有出错了，因为是逻辑错误没有奔溃。然后出错了也没有将IsLastData设置为最后一页，所以没有地方跳出循环。然后就卡死在这里了。
至此真想大白，是我们的条件写的有问题，死循环了，而不是最开始定位的Socket 长时间未响应。
关于这种死循环取数据的，一定要设置通用的跳出条件，一般情况下可以设置Deadline 设置某一个时间内还没有执行完的话，跳出，可以设置尝试重试次数，比如说1000次，还没有结论，就跳出。然后记录Debug日志，方便将来断言这个地方确实是有问题。然后尝试修复这个问题。
