一次因HashSet引起的并發(fā)問題詳解
為啥要用HahSet?
假如我們現(xiàn)在想要在一大堆數(shù)據(jù)中查找X數(shù)據(jù)。LinkedList的數(shù)據(jù)結(jié)構(gòu)就不說了,查找效率低的可怕。ArrayList哪,如果我們不知道X的位置序號,還是一樣要全部遍歷一次直到查到結(jié)果,效率一樣可怕。HashSet天生就是為了提高查找效率的。
背景
上午剛到公司,準備開始一天的摸魚之旅時突然收到了一封監(jiān)控中心的郵件。
心中暗道不好,因為監(jiān)控系統(tǒng)從來不會告訴我應用完美無 bug,其實系統(tǒng)挺猥瑣。
打開郵件一看,果然告知我有一個應用的線程池隊列達到閾值觸發(fā)了報警。
由于這個應用出問題非常影響用戶體驗;于是立馬讓運維保留現(xiàn)場 dump 線程和內(nèi)存同時重啟應用,還好重啟之后恢復正常。于是開始著手排查問題。
分析
首先了解下這個應用大概是做什么的。
簡單來說就是從 MQ 中取出數(shù)據(jù)然后丟到后面的業(yè)務線程池中做具體的業(yè)務處理。
而報警的隊列正好就是這個線程池的隊列。
跟蹤代碼發(fā)現(xiàn)構(gòu)建線程池的方式如下:
ThreadPoolExecutor executor = new ThreadPoolExecutor(coreSize, maxSize, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());; put(poolName,executor);
采用的是默認的 LinkedBlockingQueue 并沒有指定大小(這也是個坑),于是這個隊列的默認大小為 Integer.MAX_VALUE。
由于應用已經(jīng)重啟,只能從僅存的線程快照和內(nèi)存快照進行分析。
內(nèi)存分析
先利用 MAT 分析了內(nèi)存,的到了如下報告。

其中有兩個比較大的對象,一個就是之前線程池存放任務的 LinkedBlockingQueue,還有一個則是 HashSet。
當然其中隊列占用了大量的內(nèi)存,所以優(yōu)先查看,HashSet 一會兒再看。
由于隊列的大小給的夠大,所以結(jié)合目前的情況來看應當是線程池里的任務處理較慢,導致隊列的任務越堆越多,至少這是目前可以得出的結(jié)論。
線程分析
再來看看線程的分析,這里利用fastthread.io 這個網(wǎng)站進行線程分析。
因為從表現(xiàn)來看線程池里的任務遲遲沒有執(zhí)行完畢,所以主要看看它們在干嘛。
正好他們都處于 RUNNABLE 狀態(tài),同時堆棧如下:

發(fā)現(xiàn)正好就是在處理上文提到的 HashSet,看這個堆棧是在查詢 key 是否存在。通過查看 312 行的業(yè)務代碼確實也是如此。
這里的線程名字也是個坑,讓我找了好久。
定位
分析了內(nèi)存和線程的堆棧之后其實已經(jīng)大概猜出一些問題了。
這里其實有一個前提忘記講到:
這個告警是凌晨三點發(fā)出的郵件,但并沒有電話提醒之類的,所以大家都不知道。
到了早上上班時才發(fā)現(xiàn)并立即 dump 了上面的證據(jù)。
所有有一個很重要的事實:這幾個業(yè)務線程在查詢 HashSet 的時候運行了 6 7 個小時都沒有返回。
通過之前的監(jiān)控曲線圖也可以看出:

操作系統(tǒng)在之前一直處于高負載中,直到我們早上看到報警重啟之后才降低。
同時發(fā)現(xiàn)這個應用生產(chǎn)上運行的是 JDK1.7 ,所以我初步認為應該是在查詢 key 的時候進入了 HashMap 的環(huán)形鏈表導致 CPU 高負載同時也進入了死循環(huán)。
為了驗證這個問題再次 review 了代碼。
整理之后的偽代碼如下:
//線程池
private ExecutorService executor;
private Set<String> set = new hashSet();
private void execute(){
while(true){
//從 MQ 中獲取數(shù)據(jù)
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)){
//數(shù)據(jù)庫查詢
if(queryDB(key)){
set.add(key);
return;
}
}
//達到某種條件時清空 set
if(flag){
set = null ;
}
}
}
大致的流程如下:
- 源源不斷的從 MQ 中獲取數(shù)據(jù)。
- 將數(shù)據(jù)丟到業(yè)務線程池中。
- 判斷數(shù)據(jù)是否已經(jīng)寫入了 Set。
- 沒有則查詢數(shù)據(jù)庫。
- 之后寫入到 Set 中。
這里有一個很明顯的問題,那就是作為共享資源的 Set 并沒有做任何的同步處理。
這里會有多個線程并發(fā)的操作,由于 HashSet 其實本質(zhì)上就是 HashMap,所以它肯定是線程不安全的,所以會出現(xiàn)兩個問題:
- Set 中的數(shù)據(jù)在并發(fā)寫入時被覆蓋導致數(shù)據(jù)不準確。
- 會在擴容的時候形成環(huán)形鏈表。
第一個問題相對于第二個還能接受。
通過上文的內(nèi)存分析我們已經(jīng)知道這個 set 中的數(shù)據(jù)已經(jīng)不少了。同時由于初始化時并沒有指定大小,僅僅只是默認值,所以在大量的并發(fā)寫入時候會導致頻繁的擴容,而在 1.7 的條件下又可能會形成環(huán)形鏈表。
不巧的是代碼中也有查詢操作(contains()),觀察上文的堆棧情況:

發(fā)現(xiàn)是運行在 HashMap 的 465 行,來看看 1.7 中那里具體在做什么:

已經(jīng)很明顯了。這里在遍歷鏈表,同時由于形成了環(huán)形鏈表導致這個 e.next 永遠不為空,所以這個循環(huán)也不會退出了。
到這里其實已經(jīng)找到問題了,但還有一個疑問是為什么線程池里的任務隊列會越堆越多。我第一直覺是任務執(zhí)行太慢導致的。
仔細查看了代碼發(fā)現(xiàn)只有一個地方可能會慢:也就是有一個數(shù)據(jù)庫的查詢。
把這個 SQL 拿到生產(chǎn)環(huán)境執(zhí)行發(fā)現(xiàn)確實不快,查看索引發(fā)現(xiàn)都有命中。
但我一看表中的數(shù)據(jù)發(fā)現(xiàn)已經(jīng)快有 7000W 的數(shù)據(jù)了。同時經(jīng)過運維得知 MySQL 那臺服務器的 IO 壓力也比較大。
所以這個原因也比較明顯了:
由于每消費一條數(shù)據(jù)都要去查詢一次數(shù)據(jù)庫,MySQL 本身壓力就比較大,加上數(shù)據(jù)量也很高所以導致這個 IO 響應較慢,導致整個任務處理的就比較慢了。
但還有一個原因也不能忽視;由于所有的業(yè)務線程在某個時間點都進入了死循環(huán),根本沒有執(zhí)行完任務的機會,而后面的數(shù)據(jù)還在源源不斷的進入,所以這個隊列只會越堆越多!
這其實是一個老應用了,可能會有人問為什么之前沒出現(xiàn)問題。
這是因為之前數(shù)據(jù)量都比較少,即使是并發(fā)寫入也沒有出現(xiàn)并發(fā)擴容形成環(huán)形鏈表的情況。這段時間業(yè)務量的暴增正好把這個隱藏的雷給揪出來了。所以還是得信墨菲他老人家的話。
總結(jié)
至此整個排查結(jié)束,而我們后續(xù)的調(diào)整措施大概如下:
- HashSet 不是線程安全的,換為 ConcurrentHashMap同時把 value 寫死一樣可以達到 set 的效果。
- 根據(jù)我們后面的監(jiān)控,初始化 ConcurrentHashMap 的大小盡量大一些,避免頻繁的擴容。
- MySQL 中很多數(shù)據(jù)都已經(jīng)不用了,進行冷熱處理。盡量降低單表數(shù)據(jù)量。同時后期考慮分表。
- 查數(shù)據(jù)那里調(diào)整為查緩存,提高查詢效率。
- 線程池的名稱一定得取的有意義,不然是自己給自己增加難度。
- 根據(jù)監(jiān)控將線程池的隊列大小調(diào)整為一個具體值,并且要有拒絕策略。
- 升級到 JDK1.8。
- 再一個是報警郵件酌情考慮為電話通知😂。
HashMap 的死循環(huán)問題在網(wǎng)上層出不窮,沒想到還真被我遇到了?,F(xiàn)在要滿足這個條件還是挺少見的,比如 1.8 以下的 JDK 這一條可能大多數(shù)人就碰不到,正好又證實了一次墨菲定律。
好了,以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
相關文章
實戰(zhàn)SpringBoot集成JWT實現(xiàn)token驗證
本文詳細講解了SpringBoot集成JWT實現(xiàn)token驗證,文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-12-12
Java文件讀寫IO/NIO及性能比較詳細代碼及總結(jié)
這篇文章主要介紹了Java文件讀寫IO/NIO及性能比較詳細代碼及總結(jié),具有一定借鑒價值,需要的朋友可以參考下。2017-12-12
SpringBoot實現(xiàn)HTTP服務監(jiān)聽的代碼示例
前后端分離項目中,在調(diào)用接口調(diào)試時候,我們可以通過cpolar內(nèi)網(wǎng)穿透將本地服務端接口模擬公共網(wǎng)絡環(huán)境遠程調(diào)用調(diào)試,本次教程我們以Java服務端接口為例,需要的朋友可以參考下2023-05-05
Java的動態(tài)綁定與雙分派_動力節(jié)點Java學院整理
這篇文章主要介紹了Java的動態(tài)綁定與雙分派,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-08-08
Spring中的@Value和@PropertySource注解詳解
這篇文章主要介紹了Spring中的@Value和@PropertySource注解詳解,@PropertySource:讀取外部配置文件中的key-value保存到運行的環(huán)境變量中,本文提供了部分實現(xiàn)代碼,需要的朋友可以參考下2023-11-11
SpringBoot服務設置禁止server.point端口的使用
本文主要介紹了SpringBoot服務設置禁止server.point端口的使用,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2024-01-01

