你好呀，我是歪歪。

前幾天我在網(wǎng)上沖浪，看到一個哥們在吐槽，說他工作三年多了，沒使用過多線程。

雖然八股文背的滾瓜爛熟，但是沒有在實際開發(fā)過程中寫的都是業(yè)務(wù)代碼，沒有使用過線程池，心里還是慌得一比。

我只是微微一笑，這不是很正常嗎？

業(yè)務(wù)代碼中一般也使不上多線程，或者說，業(yè)務(wù)代碼中不知不覺你以及在使用線程池了，你再 duang 的一下搞一個出來，反而容易出事。

所以提到線程池的時候，我個人的觀點是必須把它吃得透透的，但是在業(yè)務(wù)代碼中少用或者不用多線程。

關(guān)于這個觀點，我給你盤一下。

Demo

首先我們還是花五分鐘搭個 Demo 出來。

我手邊剛好有一個之前搭的一個關(guān)于 Dubbo 的 Demo，消費者、生產(chǎn)者都有，我就直接拿來用了：

這個 Demo 我也是跟著網(wǎng)上的 quick start 搞的：

https://cn.dubbo.apache.org/zh-cn/overview/quickstart/java/spring-boot/

可以說寫的非常詳細了，你就跟著官網(wǎng)的步驟一步步的搞就行了。

我這個 Demo 稍微不一樣的是我在消費者模塊里面搞了一個 Http 接口：

在接口里面發(fā)起了 RPC 調(diào)用，模擬從前端頁面發(fā)起請求的場景，更加符合我們的開發(fā)習(xí)慣。

而官方的示例中，是基于了 SpringBoot 的 CommandLineRunner 去發(fā)起調(diào)用：

只是發(fā)起調(diào)用的方式不一樣而已，其他沒啥大區(qū)別。

需要說明的是，我只是手邊剛好有一個 Dubbo 的 Demo，隨手就拿來用了，但是本文想要表達的觀點，和你使不使用 Dubbo 作為 RPC 框架，沒有什么關(guān)系，道理是通用的。

上面這個 Demo 啟動起來之后，通過 Http 接口發(fā)起一次調(diào)用，看到控制臺服務(wù)提供方和服務(wù)消費方都有對應(yīng)的日志輸出，準(zhǔn)備工作就算是齊活兒了：

上菜

在上面的 Demo 中，這是消費者的代碼：

這是提供者的代碼：

整個調(diào)用鏈路非常的清晰：

來，請你告訴我這里面有線程池嗎？

沒有！

是的，在日常的開發(fā)中，我就是寫個接口給別人調(diào)用嘛，在我的接口里面并沒有線程池相關(guān)的代碼，只有 CRUD 相關(guān)的業(yè)務(wù)代碼。

同時，在日常的開發(fā)中，我也經(jīng)常調(diào)用別人提供給我的接口，也是一把梭，擼到底，根本就不會用到線程池。

所以，站在我，一個開發(fā)人員的角度，這個里面沒有線程池。

合理，非常合理。

但是，當(dāng)我們換個角度，再看看，它也是可以有的。

比如這樣：

反應(yīng)過來沒有？

我們發(fā)起一個 Http 調(diào)用，是由一個 web 容器來處理這個請求的，你甭管它是 Tomcat，還是 Jetty、Netty、Undertow 這些玩意，反正是個 web 容器在處理。

那你說，這個里面有線程池嗎？

在方法入口處打個斷點，這個 http-nio-8081-exec-1 不就是 Tomcat 容器線程池里面的一個線程嗎：

通過 dump 堆棧信息，過濾關(guān)鍵字可以看到這樣的線程，在服務(wù)啟動起來，啥也沒干的情況下，一共有 10 個：

朋友，這不就是線程池嗎？

雖然不是你寫的，但是你確實用了。

我寫出來的這個 test 接口，就是會由 web 容器中的一個線程來進行調(diào)用。所以，站在 web 容器的角度，這里是有一個線程池的：

同理，在 RPC 框架中，不管是消費方，還是服務(wù)提供方，也都存在著線程池。

比如 Dubbo 的線程池，你可以看一下官方的文檔：

https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/advanced-features-and-usage/performance/threading-model/

而對于大多數(shù)的框架來說，它絕不可能只有一個線程池，為了做資源隔離，它會啟用好幾個線程池，達到線程池隔離，互不干擾的效果。

比如參與 Dubbo 一次調(diào)用的其實不僅一個線程池，至少還有 IO 線程池和業(yè)務(wù)線程池，它們各司其職：

我們主要關(guān)注這個業(yè)務(wù)線程池。

反正站在 Dubbo 框架的角度，又可以補充一下這個圖片了：

那么問題來了，在當(dāng)前的這個情況下？

當(dāng)有人反饋：哎呀，這個服務(wù)吞吐量怎么上不去啊？

你怎么辦？

你會 duang 的一下在業(yè)務(wù)邏輯里面加一個線程池嗎？

大哥，前面有個 web 容器的線程池，后面有個框架的線程池，兩頭不調(diào)整，你在中間加個線程池，加它有啥用啊？

web 容器，拿 Tomcat 來說，人家給你提供了線程池參數(shù)調(diào)整的相關(guān)配置，這么一大坨配置，你得用起來啊：

https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html

再比如 Dubbo 框架，都給你明說了，這些參數(shù)屬于性能調(diào)優(yōu)的范疇，感覺不對勁了，你先動手調(diào)調(diào)啊：

你把這些參數(shù)調(diào)優(yōu)弄好了，絕對比你直接懟個線程池在業(yè)務(wù)代碼中，效果好的多。

甚至，你在業(yè)務(wù)代碼中加入一個線程池之后，反而會被“反噬”。

比如，你 duang 的一下懟個線程池在這里，我們先只看 web 容器和業(yè)務(wù)代碼對應(yīng)的部分：

由于你的業(yè)務(wù)代碼中有線程池的存在，所以當(dāng)接受到一個 web 請求之后，立馬就把請求轉(zhuǎn)發(fā)到了業(yè)務(wù)線程池中，由線程池中的線程來處理本次請求，從而釋放了 web 請求對應(yīng)的線程，該線程又可以里面去處理其他請求。

這樣來看，你的吞吐量確實上去了。

在前端來看，非常的 nice，請求立馬得到了響應(yīng)。

但是，你考慮過下游嗎？

你的吞吐量上漲了，下游同一時間處理的請求就變多了。如果下游跟不上處理，頂不住了，直接就是崩給你看怎么辦？

而且下游不只是你一個調(diào)用方，由于你調(diào)用的太猛，導(dǎo)致其他調(diào)用方的請求響應(yīng)不過來，是會引起連鎖反應(yīng)的。

所以，這種場景下，為了異步懟個線程池放著，我覺得還不如用消息隊列來實現(xiàn)異步化，頂天了也就是消息堆積嘛，總比服務(wù)崩了好，這樣更加穩(wěn)妥。

或者至少和下游勾兌一下，問問我們這邊吞吐量上升，你們扛得住不。

有的小伙伴看到這里可能就會產(chǎn)生一個疑問了：歪師傅，你這個講得怎么和我背的八股文不一樣啊？

巧了，你背過的八股文我也背過，現(xiàn)在我們來溫習(xí)一下我們背過的八股文。

什么時候使用線程池呢？

比如一個請求要經(jīng)過若干個服務(wù)獲取數(shù)據(jù)，且這些數(shù)據(jù)沒有先后依賴，最終需要把這些數(shù)據(jù)組合起來，一并返回，這樣經(jīng)典的場景：

用戶點商品詳情，你要等半天才展示給用戶，那用戶肯定罵罵咧咧的久走了。

這個時候，八股文上是怎么說的：用線程池來把串行的動作改成并行。

這個場景也是增加了服務(wù) A 的吞吐量，但是用線程池就是非常正確的，沒有任何毛病。

但是你想想，我們最開始的這個案例，是這個場景嗎？

我們最開始的案例是想要在業(yè)務(wù)邏輯中增加一個線程池，對著一個下游服務(wù)就是一頓猛攻，不是所謂的串行改并行，而是用更多的線程，帶來更多的串行。

這已經(jīng)不是一個概念了。

還有一種場景下，使用線程池也是合理的。

比如你有一個定時任務(wù)，要從數(shù)據(jù)庫中撈出狀態(tài)為初始化的數(shù)據(jù)，然后去調(diào)用另外一個服務(wù)的接口查詢數(shù)據(jù)的最終狀態(tài)。

如果你的業(yè)務(wù)代碼是這樣的：

//獲取訂單狀態(tài)為初始化的數(shù)據(jù)(0:初始化?1:處理中?2:成功?3:失敗)
//select?*?from?order?where?order_status=0;
ArrayList?initOrderInfoList?=?queryInitOrderInfoList();
//循環(huán)處理這批數(shù)據(jù)
for(OrderInfo?orderInfo?:?initOrderInfoList){
????//捕獲異常以免一條數(shù)據(jù)錯誤導(dǎo)致循環(huán)結(jié)束
????try{
????????//發(fā)起rpc調(diào)用
????????String?orderStatus?=?queryOrderStatus(orderInfo.getOrderId);
????????//更新訂單狀態(tài)
????????updateOrderInfo(orderInfo.getOrderId,orderStatus);??
????}?catch?(Exception?e){
????????//打印異常
????}
}

雖然你框架中使用了線程池，但是你就是在一個 for 循環(huán)中不停的去調(diào)用下游服務(wù)查詢數(shù)據(jù)狀態(tài)，是一條數(shù)據(jù)一條數(shù)據(jù)的進行處理，所以其實同一時間，只是使用了框架的線程池中的一個線程。

為了更加快速的處理完這批數(shù)據(jù)，這個時候，你就可以懟一個線程池放在 for 循環(huán)里面了：

//循環(huán)處理這批數(shù)據(jù)
for(OrderInfo?orderInfo?:?initOrderInfoList){
????//使用線程池
????executor.execute(()?->?{
????????//捕獲異常以免一條數(shù)據(jù)錯誤導(dǎo)致循環(huán)結(jié)束
????????try?{
????????????//發(fā)起rpc調(diào)用
????????????String?orderStatus?=?queryOrderStatus(orderInfo.getOrderId);
????????????//更新訂單狀態(tài)
????????????updateOrderInfo(orderInfo.getOrderId,?orderStatus);
????????}?catch?(Exception?e)?{
????????????//打印異常
????????}
????});
}

需要注意的是，這個線程池的參數(shù)怎么去合理的設(shè)置，是需要考慮的事情。

同時這個線程池的定位，就類似于 web 容器線程池的定位。

或者這樣對比起來看更加清晰一點：

定時任務(wù)觸發(fā)的時候，在發(fā)起遠程接口調(diào)用之前，沒有線程池，所以我們可以啟用一個線程池來加快數(shù)據(jù)的處理。

而 Http 調(diào)用或者 RPC 調(diào)用，框架中本來就已經(jīng)有一個線程池了，而且也給你提供了對應(yīng)的性能調(diào)優(yōu)參數(shù)配置，那么首先考慮的應(yīng)該是把這個線程池充分利用起來。

如果僅僅是因為異步化之后可以提升服務(wù)響應(yīng)速度，沒有達到串行改并行的效果，那么我更加建議使用消息隊列。

好了，本文的技術(shù)部分就到這里啦。

下面這個環(huán)節(jié)叫做[荒腔走板]，技術(shù)文章后面我偶爾會記錄、分享點生活相關(guān)的事情，和技術(shù)毫無關(guān)系。我知道看起來很突兀，但是我喜歡，因為這是一個普通博主的生活氣息。

荒腔走板

不知道你看完文章之后，有沒有產(chǎn)生一個小疑問：最開始部分的 Demo 似乎用處并不大？

是的，我最開始構(gòu)思的行文結(jié)構(gòu)是是基于 Demo 在源碼中找到關(guān)于線程池的部分，從而引出其實有一些我們“看不見的線程池”的存在的。

原本周六我是有一整天的時間來寫這篇文章，甚至周五晚上還特意把 Demo 搞定，自己調(diào)試了一番，該打的斷點全部打上，并寫完 Demo 那部分之后，我才去睡覺的，想得是第二天早上起來直接就能用。

剛好 Max 同學(xué)休年假，就回老家了，周日才回來，所以整個周六我一個人在家。

按照慣例周六睡個懶覺的，早上 11 點才起床，自己慢條斯理的做了一頓午飯，吃完飯已經(jīng)是下午 1 點多了。

本來想著在沙發(fā)上躺一會，結(jié)果一躺就是一整個下午。期間也想過起來寫一會文章，坐在電腦前又飛快的躺回到沙發(fā)上，就是覺得這個事情索然無味，當(dāng)下的那一刻就想躺著，然后無意識的刷手機，原本是拿來寫文章中關(guān)于源碼的部分的時間就這樣浪費了。

像極了高中時的我，周末帶大量作業(yè)回家，準(zhǔn)備來個懸梁刺股，彎道超車，結(jié)果變成了一睡一天，捏緊剎車。

高中的時候，時間浪費了是真的可惜。

現(xiàn)在，不一樣了。

荒腔走板這張圖片，就是我躺在沙發(fā)上的時候，別人問我在干什么時隨手拍的一張。

我并不為躺了一下午沒有干正事而感到慚愧，浪費了的時間，才是屬于自己的時間。

很久以前我看到別人在做一些浪費時間的事情的時候，我心里可能會嘀咕幾句，勸人惜時。

這兩年我不會了，允許自己做自己，允許別人做別人。