本文來自作者投稿，原創作者：Tom

前景提要

早上9點第一個到公司泡了一包枸杞，準備打開極客時間看兩篇文章提提神。突然客服部反饋用戶發送短信收取不到驗證碼還一通在有大領導的群里@所有人（負責這塊的同事還沒來!!!）。

排查思路

第一時間查看消息中心日志，發現果不其然出現報錯：

MessageService. Last error is:?Failed to?invoke remote method: threadpool is?exhausted ,detail msg:Thread?pool is?EXHAUSTED! Thread Name: Pool Size: 200?(active: 200, core: 200, max: 200, largest:?200), Task: 16150?(completed: 15950)RemotingException: Server side(192.168.10.65,18090) threadpool is?exhausted ,detail msg:Thread?pool is?EXHAUSTED!刪減了一些敏感錯誤信息，不影響排查問題

看到Thread pool is EXHAUSTED幾個關鍵字， 于是馬上定位下游的短信服務肯定是爆了。 第一時間腦海中浮現的幾個可能性是：

• 情況一： 被人攻擊，頻繁盜刷， 導致接口請求超限

• 情況二： 下游短信服務發送短信接口出現問題， 處理緩慢導致。最終導致請求超限

根據第一種情況， 簡單的對當天請求驗證碼接口日志做了分析， 發現請求頻率正常， 并不頻繁，于是排除了第一種情況。

根據第二種情況查看并分析， 發現在半小時前消息中心請求短信服務接口超時，報錯信息如下：

com.alibaba.dubbo.remoting.TimeoutException: Waiting?server-side?response?timeout?by?scan?timer. client?elapsed: 0 ms, server?elapsed: 20020 ms, timeout: 20000 ms

看到上面的超時異常信息更加堅定了第二種情況的判斷。 最后查看下游短信服務發送短信接口日志，果不其然發現如下異常：

com.alibaba.druid.pool.DruidDataSource - create?connection?SQLException, url: jdbc:mysql:...., errorCode 9001, state HY000 java.sql.SQLException: Max?connect?timeout?reached while?reaching hostgroup 90?after?10985ms

What！獲取數據庫連接超時？喝了一口剛剛泡好的枸杞（此時溫度剛剛好），想到幾個可疑點：

短信服務中其他接口出現問題，執行緩慢并持有數據庫連接沒有進行釋放。

短信服務的發送接口邏輯應該只是封裝統一調用第三方短信平臺， 可能由于第三方接口緩慢導致

最終排查發現， 是由于短信發送接口請求第三方短信平臺不穩定導致。

優化方案

review了短信接口代碼， 里面只是做了簡單的第三方短信平臺api統一封裝， 并不需要操作數據庫更不需要事物(小伙伴為了方便還在類上面友好的加了@Transaction！) ，這時第三方短信平臺請求緩慢時一直持有數據庫連接。

針對第三方短信平臺做故障處理機制。

歡迎各位補充。

如果你看完有收獲，歡迎給作者贊賞。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的Dubbo 线上 Thread pool is EXHAUSTED 问题排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。