经过几天漫长的问题分析、处理、测试、验证，定时器Timer终于定时了，于是开始了这篇文章，希望对还在纠结于“定时器Timer不定时”的同学有所帮助，现在的方案，在系统日志中会有警告，如果您有更好的方案，也请不吝赐教。

　　先交代下背景吧：“订单审核后，商家3分钟内未确认的订单，自动生成催单记录，客服通过催单记录联系商家，于是，我们就用的System.Threading.Timer 来作来定时器”。下图为Timer初始化部分代码：

　　

因为是重要客户，我们本地测试服务器都经过自认为严格的测试后，才提交正式服务器。可是，每次提交正式服务器后，每天总有几个时间段不定时生成催单记录，然后我们自己测试又都正常，于是不了了之！反复几次，客户不高兴了，领导怒了，做为程序员的我，才开始冷静了，到底哪里出了问题？

　　1.消失的33分钟

　　当然，首先，还是检查网站中程序记录的日志，因为我们定时程序是每分钟执行一次（因为是多个任务，每个任务执行的时间间隔是不一样的，所以每分钟判断哪个任务可以执行），所以日志是比较容易查询的，于是，看到了下图：

　　

网站在这个时间点上，没任何错误信息，服务器在这个点上也没任何人为操作。当确认程序上基本没有问题，我开始查询系统日志了。

　　2.应用程序池工作进程被回收

　　知道这个时间点出问题了，在系统日志中我很快找到了此时间的日志，于是看到了下图：

　　

原来是没有访问，被回收了，直到有人访问时，再创建进程，到这里才明白，为什么我们测试都正常，因为我们测试时，一直在访问，所以一切正常。

　　3.让网站自己访问自己

　　当知道问题后，就开始纠结处理方案了，有人说写服务器程序，创建一个服务，让此服务去生成催单，但因为是正式服务器，我们没办法链接的，所以此方案虽好，但对我们来说不切实际；google了下，找到一个自认为简单、可行的方案，如下图（不记得来源了，见谅）：

发布后，测试了几个小时，呀，还真正常了，于是通知客户测试。结果，还是如前几次一样，他们一用就出问题了。只能继续查看系统日志...

　　4.进程在关闭过程中超出时间限制

　　虽然结果还是一样，但是我们离真相越来越近了，找到出错时间点前后的网站日志和系统日志，看到了下图的信息：

　  网站日志：

系统日志：

　　

　　5.程序池配置

　　看到上图的问题，我最先想到的还是对程序池进行配置，之前对这方便了解也不多，也google了一个比较文明的配置，然后根据情况调整了几个参数：

　　

修改配置后，问题依然存在，路在何方？

　　6.失败不可怕，再来一次！

　　回收时，访问失败，如果过15s再访问呢，是的，失败不可怕，再来一次，于是，有了下面的代码：

　　

　　发布、测试，1小时正常，3小时正常，8小时正常，24小时正常，30小时正常，心总算能踏实了，但是回头想了下，进程都回收了，为什么再访问一次程序会执行，IIS日志中每次回收时，都只有一条访问记录，只有得空时再好好研究下了！

　　写了几年代码，还是第一次，通过这么多日志，特别是服务器的日志来解决问题，过程虽然漫长，但还是苦并快乐着！！！

　　30小时正常，也许到80小时，160小时，又会有问题了，持续关注中...

　　

　　成为一名优秀的程序员！