背景描述：使用quartz建立多個定時任務，每5分鐘執行一次。定時任務中包含httpclient的網絡訪問，及druid的數據庫訪問。執行一段時間后不定期（可能10天半個月，可能好幾個月）卡死。
表現狀況為：

日志到某個時間點突然沒有輸出了，也沒有異常日志記錄，排除當時磁盤空間不足的問題

httpclient使用的4.3版本，出問題的生成環境下已在request中設置3種超時時間。實際測試中除了setConnectTimeout與setConnectionRequestTimeout即使不設置，程序也會拋出超時異常。只有當setSocketTimeout不設置的時候，程序會出現日志不打印一直卡死的狀況，但與我要解決的問題來看還是有略微區別。當時的內存狀況不一致。（圖1為生產環境上卡死時的內存，圖2為本機測試時，故意不設置setSocketTimeout超時情況下的內存圖 ）
（圖1）（圖2）

生成環境下設置了數據庫超時，本機測試時暫時還沒有測試數據庫超時的情況。

下次生成環境上再發生此類狀況的排查步驟：

本機打開jdk安裝目錄下的visualVM查看線程執行情況，正常定時任務執行時線程應該是如下圖的少量runnalbe，如圖1所示，但是本機測試時，故意讓服務器端下斷點不返回信息，在客戶端的httpclient中不設置setConnectTimeout超時時間，最終顯示的線程圖樣是一直runnalbe的，因此下次在生產環境下出現這個問題時，可以查看線程中，該線程是否一直是runnalbe狀態如圖2所示
（圖1） （圖2）
使用jstack查看當時的業務定時任務線程中具體代碼。打開步驟，找到程序對應的pid，然后使用命令jstack 程序pid的方式查看線程狀態（圖1）。 使用jstack的原因是這個可以看到具體代碼，如圖2
（圖1）（圖2）

今天又發生了一次，排查懷疑是數據庫連接未釋放造成的。

（發生問題的機器上，線程圖。從中可以看到執行定時job的線程pool-3-thread-1一直在運行，類似于之前在本地機器上模擬的httpclient未設置響應時間的狀態）

（發生問題的機器上，內存圖）

---

總結

以上是生活随笔為你收集整理的定时任务卡死问题排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。