通過日誌觀察到任務執行一段時間後停止工作
先介紹一下業務邏輯，任務通過乙個介面觸發，會在乙個單執行緒的執行緒池中開啟乙個任務，任務邏輯為不斷從資料庫中查詢出資料並將資料放入乙個阻塞佇列中等待消費者消費。消費者會單執行緒迴圈不斷從佇列中獲取訊息，然後放入執行緒池之中執行。消費者執行緒池中線程執行的邏輯為傳送http請求，通過響應的結果回寫資料。
ok，整個業務邏輯很簡單，讓我們開始排查故障吧。
檢查資料庫之後發現仍有未執行任務，因此排除此問題
我檢視了伺服器狀態，發現cpu使用率很低，因此排除是死迴圈導致
結果一切正常，因此排除資料庫死鎖問題
這裡圖忘記儲存了
檢視之後發現gc很正常，沒有fullgc，因此排除gc導致的問題
到這裡我發現我的日誌不夠，於是補充大量日誌之後開始第二輪排查
觀察日誌過程中發現，消費者端線程池中的執行緒會漸漸停止工作
我們用jstack看下執行緒狀態
觀察發現，消費者執行緒都處於runnable狀態，並未發生阻塞
ps.劃重點。現在回想起來，這裡嚴重誤導了我的判斷
dump之後發現記憶體一切正常，從記憶體內容中能看出來消費者執行緒池中的執行緒並未死亡。
這裡我就又開始了陷入了自我懷疑之中，是不是邏輯**出了問題，於是我開始了反覆的自我折磨，反覆的進行各種設想。
經過一段漫長的折騰，我突然想到，任務中既然有http請求那麼我看下鏈結狀態吧
這麼一看，發現問題了，目前所有消費者執行緒都處於停止狀態，但鏈結都是established，這肯定有問題
於是開始檢視resttemplate原始碼，發現預設超時時間都是0，代表不超時一直等待
這就好辦了，我們只需要設定好超時時間就ok了
設定後發現任務執行正常，問題得到解決
此次故障問題算不上覆雜，但由於問題的復現需要依賴網路偶然的問題，需要的時間較長，因此排查起來非常難受。
現在想來
1、我犯了乙個想當然的錯誤，那就是執行緒是runnable狀態代表執行緒未發生阻塞.
這其實是乙個慣性思維，因為平時遇到的阻塞情況執行緒要麼處於waitting狀態，要麼處於blocking狀態，因此看到runnable就覺得沒問題，因此花費了大量的排查時間。
2、應該多加一些監控的日誌，方便排查問題
3、是要熟悉各種元件，了解其核心之後再進行使用，並在使用時根據具體情況定製核心引數
由「彈窗之見」引發的小分析
自從石榴姐來了之後，不知道多少 將要 敗倒 在她的石榴裙下？官方做出的宣告中表示 含有大量妨礙使用者正常瀏覽的惡劣廣告的頁面，尤其以彈出大量低質彈窗廣告 混淆頁面主體內容的垃圾廣告頁面 將成為石榴姐嚴重打擊的物件。日前，彈窗在站長們的口中成為熱門的話題，彈窗是否成為建站的禁忌呢？小編就從乙個使用者的...
由 引發的思考
前陣子在乙個移動專案中，通過 的方式 繫結click 事件來提交乙個表單，由於表單資訊比較敏感，於是採用的post 同步提交的方式，原本到也沒有什麼。後來萬惡的pm說 你這個按鈕呀，要固定在底部比較好 於是乎就通過 position fixed 固定到底部了。那麼，問題來了 在ios 下，虛擬鍵盤是...
演示 引發的次優路徑故障分析與排除
演示 引發的次優路徑故障分析與排除 故障背景 如圖14.1所示的網路環境，在所包含的區域啟動了ospf路由，當然路由器r1的e1 0和r2的e1 0這段10mb的乙太網鏈路沒有被包含到ospf的路由域中，由於某些特殊原因，在這一段鏈路將使用靜態路由來到達172.17.100.0的子網，具體每台路由器...