經過幾天漫長的問題分析、處理、測試、驗證，定時器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小時，又會有問題了，持續關注中...
成為一名優秀的程序員！