背景
上午剛到公司，準備開始一天的摸魚之旅時突然收到了一封監控中心的郵件。

心中暗道不好，因為監控系統從來不會告訴我應用完美無 bug，其實系統挺猥瑣。

開啟郵件一看，果然告知我有一個應用的執行緒池佇列達到閾值觸發了報警。

由於這個應用出問題非常影響使用者體驗；於是立馬讓運維保留現場 dump 執行緒和記憶體同時重啟應用，還好重啟之後恢復正常。於是開始著手排查問題。
分析
首先了解下這個應用大概是做什麼的。

簡單來說就是從 MQ 中取出資料然後丟到後面的業務執行緒池中做具體的業務處理。

而報警的佇列正好就是這個執行緒池的佇列。

跟蹤程式碼發現構建執行緒池的方式如下：

ThreadPoolExecutor executor = new ThreadPoolExecutor(coreSize, maxSize,
 0L, TimeUnit.MILLISECONDS,
 new LinkedBlockingQueue<Runnable>());;
 put(poolName,executor);
 

採用的是預設的 LinkedBlockingQueue 並沒有指定大小（這也是個坑），於是這個佇列的預設大小為 Integer.MAX_VALUE。

由於應用已經重啟，只能從僅存的執行緒快照和記憶體快照進行分析。
記憶體分析

先利用 MAT 分析了記憶體，的到了如下報告。

一次 HashSet 所引起的併發問題

其中有兩個比較大的物件，一個就是之前執行緒池存放任務的 LinkedBlockingQueue，還有一個則是 HashSet。

當然其中佇列佔用了大量的記憶體，所以優先檢視，HashSet 一會兒再看。

由於佇列的大小給的夠大，所以結合目前的情況來看應當是執行緒池裡的任務處理較慢，導致佇列的任務越堆越多，至少這是目前可以得出的結論。
執行緒分析

再來看看執行緒的分析，這裡利用 fastthread.io 這個網站進行執行緒分析。

因為從表現來看執行緒池裡的任務遲遲沒有執行完畢，所以主要看看它們在幹嘛。

正好他們都處於 RUNNABLE 狀態，同時堆疊如下：

發現正好就是在處理上文提到的 HashSet，看這個堆疊是在查詢 key 是否存在。通過檢視 312 行的業務程式碼確實也是如此。

這裡的執行緒名字也是個坑，讓我找了好久。

定位
分析了記憶體和執行緒的堆疊之後其實已經大概猜出一些問題了。

這裡其實有一個前提忘記講到：

這個告警是凌晨三點發出的郵件，但並沒有電話提醒之類的，所以大家都不知道。

到了早上上班時才發現並立即 dump 了上面的證據。

所有有一個很重要的事實：這幾個業務執行緒在查詢 HashSet 的時候運行了 6 7 個小時都沒有返回。

通過之前的監控曲線圖也可以看出：

作業系統在之前一直處於高負載中，直到我們早上看到報警重啟之後才降低。

同時發現這個應用生產上執行的是 JDK1.7 ，所以我初步認為應該是在查詢 key 的時候進入了 HashMap 的環形連結串列導致 CPU 高負載同時也進入了死迴圈。

為了驗證這個問題再次 review 了程式碼。

整理之後的虛擬碼如下：

//執行緒池
private ExecutorService executor;
private Set<String> set = new hashSet();
private void execute(){

while(true){
//從 MQ 中獲取資料
String key = subMQ();
executor.excute(new Worker(key)) ;
}
}
public class Worker extends Thread{
private String key ;
public Worker(String key){
this.key = key;br/>}
@Override
private void run(){
if(!set.contains(key)){
//資料庫查詢
if(queryDB(key)){
set.add(key);
return;
}
}
//達到某種條件時清空 set
if(flag){
set = null ;
}
}
}
大致的流程如下：