一次 HashSet 所引發的併發問題

時間 2019-11-10

標籤一次 hashset 引發併發問題欄目 Java 简体版

原文原文鏈接

背景

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

心中暗道很差，由於監控系統歷來不會告訴我應用完美無 bug，其實系統挺猥瑣。數據庫

打開郵件一看，果真告知我有一個應用的線程池隊列達到閾值觸發了報警。緩存

因爲這個應用出問題很是影響用戶體驗；因而立馬讓運維保留現場 dump 線程和內存同時重啓應用，還好重啓以後恢復正常。因而開始着手排查問題。安全

分析

首先了解下這個應用大概是作什麼的。服務器

簡單來講就是從 MQ 中取出數據而後丟到後面的業務線程池中作具體的業務處理。併發

而報警的隊列正好就是這個線程池的隊列。運維

跟蹤代碼發現構建線程池的方式以下：jsp

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

採用的是默認的 LinkedBlockingQueue 並無指定大小（這也是個坑），因而這個隊列的默認大小爲 Integer.MAX_VALUE。ide

因爲應用已經重啓，只能從僅存的線程快照和內存快照進行分析。網站

內存分析

先利用 MAT 分析了內存，的到了以下報告。

其中有兩個比較大的對象，一個就是以前線程池存聽任務的 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;
	}

	@Override
	private void run(){
		if(!set.contains(key)){

			//數據庫查詢
			if(queryDB(key)){
				set.add(key);
				return;
			}
		}

		//達到某種條件時清空 set
		if(flag){
			set = null ;
		}
	}	
}

大體的流程以下：