事件背景

系統(tǒng)相關(guān)使用人員反饋系統(tǒng)故障，日志顯示從ams系統(tǒng)服務(wù)提示dubbo處理線程不足，具體異常信息如下：

問(wèn)題定位

從上圖可知，dubbo的處理線程池滿了，默認(rèn)200個(gè)線程，活動(dòng)線程也是200個(gè)。這個(gè)現(xiàn)象非常不正常，我們的應(yīng)用并發(fā)還沒(méi)有到這個(gè)程度能同時(shí)占用200個(gè)線程處理請(qǐng)求。然后去讀了下dubbo源碼，發(fā)現(xiàn)dubbo也認(rèn)為這種情況不正常，然后幫我們記錄了應(yīng)用的線程堆棧信息，這個(gè)非常贊。代碼如下：

上面這段代碼，在線程池不夠用時(shí)，會(huì)每隔十分鐘輸出一份dump文件到用戶目錄，如：

在dump文件中，我們找到了耗盡DubboServerHandler線程池最后一個(gè)線程

通過(guò)分析得知：是我們應(yīng)用程序有段代碼導(dǎo)致的問(wèn)題，在特定條件下會(huì)觸發(fā)線程死鎖，代碼如下

代碼中定義了一個(gè)線程屏障CyclicBarrier，同行數(shù)（調(diào)用await的線程數(shù)）是11，用來(lái)處理十個(gè)線程的運(yùn)算，然后都計(jì)算完后拿到處理結(jié)果。本身代碼沒(méi)有什么問(wèn)題，在沒(méi)有并發(fā)的情況下，不會(huì)觸發(fā)問(wèn)題。但是注意中間那個(gè)箭頭，執(zhí)行線程的線程池是固定大小20的線程池，故當(dāng)同時(shí)并發(fā)數(shù)多于2個(gè)的時(shí)候線程池的線程會(huì)不夠用，導(dǎo)致線程等待，然后CyclicBarrier的main線程也會(huì)等待其他線程中的await。這就造成了相互等待，下一個(gè)請(qǐng)求過(guò)來(lái)還是繼續(xù)等待，也就是死鎖了。至此所有問(wèn)題都以清晰明朗了。

解決問(wèn)題

方案一：改CyclicBarrier為CountDownLatch，這個(gè)兩個(gè)并發(fā)工具都是jdk1.5推出為了簡(jiǎn)化并發(fā)編程，CyclicBarrier的await會(huì)占用線程池中的線程不釋放，導(dǎo)致線程不足，而CountDownLatch的count不會(huì)

方案二：改線程池類(lèi)型為CachedThreadPool，不會(huì)應(yīng)為線程池線程不夠用，導(dǎo)致相互等待

文末結(jié)語(yǔ)

java并發(fā)包提供了豐富的api來(lái)簡(jiǎn)化多線程模型的開(kāi)發(fā)，但是在針對(duì)多線程模型業(yè)務(wù)開(kāi)發(fā)時(shí)，我們還需要多留心下多線程帶來(lái)的坑?？傊嗪藭r(shí)代推薦大家多使用多線程開(kāi)發(fā)，同時(shí)，也要對(duì)使用的工具有更多的了解

以上就是線上dubbo線程池耗盡CyclicBarrier線程屏障異常的詳細(xì)內(nèi)容，更多關(guān)于dubbo線程池耗盡CyclicBarrier線程屏障的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論