你好呀,我是歪歪。
前幾天我在網上衝浪,看到一個哥們在吐槽,說他工作三年多了,沒使用過多線程。
雖然八股文背的滾瓜爛熟,但是沒有在實際開發過程中寫的都是業務代碼,沒有使用過線程池,心裏還是慌得一比。
我只是微微一笑,這不是很正常嗎?
業務代碼中一般也使不上多線程,或者說,業務代碼中不知不覺你以及在使用線程池了,你再 duang 的一下搞一個出來,反而容易出事。
所以提到線程池的時候,我個人的觀點是必須把它喫得透透的,但是在業務代碼中少用或者不用多線程。
關於這個觀點,我給你盤一下。
Demo
首先我們還是花五分鐘搭個 Demo 出來。
我手邊剛好有一個之前搭的一個關於 Dubbo 的 Demo,消費者、生產者都有,我就直接拿來用了:
這個 Demo 我也是跟着網上的 quick start 搞的:
https://cn.dubbo.apache.org/zh-cn/overview/quickstart/java/spring-boot/
可以說寫的非常詳細了,你就跟着官網的步驟一步步的搞就行了。
我這個 Demo 稍微不一樣的是我在消費者模塊裏面搞了一個 Http 接口:
在接口裏面發起了 RPC 調用,模擬從前端頁面發起請求的場景,更加符合我們的開發習慣。
而官方的示例中,是基於了 SpringBoot 的 CommandLineRunner 去發起調用:
只是發起調用的方式不一樣而已,其他沒啥大區別。
需要說明的是,我只是手邊剛好有一個 Dubbo 的 Demo,隨手就拿來用了,但是本文想要表達的觀點,和你使不使用 Dubbo 作爲 RPC 框架,沒有什麼關係,道理是通用的。
上面這個 Demo 啓動起來之後,通過 Http 接口發起一次調用,看到控制檯服務提供方和服務消費方都有對應的日誌輸出,準備工作就算是齊活兒了:
上菜
在上面的 Demo 中,這是消費者的代碼:
這是提供者的代碼:
整個調用鏈路非常的清晰:
來,請你告訴我這裏面有線程池嗎?
沒有!
是的,在日常的開發中,我就是寫個接口給別人調用嘛,在我的接口裏面並沒有線程池相關的代碼,只有 CRUD 相關的業務代碼。
同時,在日常的開發中,我也經常調用別人提供給我的接口,也是一把梭,擼到底,根本就不會用到線程池。
所以,站在我,一個開發人員的角度,這個裏面沒有線程池。
合理,非常合理。
但是,當我們換個角度,再看看,它也是可以有的。
比如這樣:
反應過來沒有?
我們發起一個 Http 調用,是由一個 web 容器來處理這個請求的,你甭管它是 Tomcat,還是 Jetty、Netty、Undertow 這些玩意,反正是個 web 容器在處理。
那你說,這個裏面有線程池嗎?
在方法入口處打個斷點,這個 http-nio-8081-exec-1 不就是 Tomcat 容器線程池裏面的一個線程嗎:
通過 dump 堆棧信息,過濾關鍵字可以看到這樣的線程,在服務啓動起來,啥也沒幹的情況下,一共有 10 個:
朋友,這不就是線程池嗎?
雖然不是你寫的,但是你確實用了。
我寫出來的這個 test 接口,就是會由 web 容器中的一個線程來進行調用。所以,站在 web 容器的角度,這裏是有一個線程池的:
同理,在 RPC 框架中,不管是消費方,還是服務提供方,也都存在着線程池。
比如 Dubbo 的線程池,你可以看一下官方的文檔:
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/advanced-features-and-usage/performance/threading-model/
而對於大多數的框架來說,它絕不可能只有一個線程池,爲了做資源隔離,它會啓用好幾個線程池,達到線程池隔離,互不干擾的效果。
比如參與 Dubbo 一次調用的其實不僅一個線程池,至少還有 IO 線程池和業務線程池,它們各司其職:
我們主要關注這個業務線程池。
反正站在 Dubbo 框架的角度,又可以補充一下這個圖片了:
那麼問題來了,在當前的這個情況下?
當有人反饋:哎呀,這個服務吞吐量怎麼上不去啊?
你怎麼辦?
你會 duang 的一下在業務邏輯裏面加一個線程池嗎?
大哥,前面有個 web 容器的線程池,後面有個框架的線程池,兩頭不調整,你在中間加個線程池,加它有啥用啊?
web 容器,拿 Tomcat 來說,人家給你提供了線程池參數調整的相關配置,這麼一大坨配置,你得用起來啊:
https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html
再比如 Dubbo 框架,都給你明說了,這些參數屬於性能調優的範疇,感覺不對勁了,你先動手調調啊:
你把這些參數調優弄好了,絕對比你直接懟個線程池在業務代碼中,效果好的多。
甚至,你在業務代碼中加入一個線程池之後,反而會被“反噬”。
比如,你 duang 的一下懟個線程池在這裏,我們先只看 web 容器和業務代碼對應的部分:
由於你的業務代碼中有線程池的存在,所以當接受到一個 web 請求之後,立馬就把請求轉發到了業務線程池中,由線程池中的線程來處理本次請求,從而釋放了 web 請求對應的線程,該線程又可以裏面去處理其他請求。
這樣來看,你的吞吐量確實上去了。
在前端來看,非常的 nice,請求立馬得到了響應。
但是,你考慮過下游嗎?
你的吞吐量上漲了,下游同一時間處理的請求就變多了。如果下游跟不上處理,頂不住了,直接就是崩給你看怎麼辦?
而且下游不只是你一個調用方,由於你調用的太猛,導致其他調用方的請求響應不過來,是會引起連鎖反應的。
所以,這種場景下,爲了異步懟個線程池放着,我覺得還不如用消息隊列來實現異步化,頂天了也就是消息堆積嘛,總比服務崩了好,這樣更加穩妥。
或者至少和下游勾兌一下,問問我們這邊吞吐量上升,你們扛得住不。
有的小夥伴看到這裏可能就會產生一個疑問了:歪師傅,你這個講得怎麼和我背的八股文不一樣啊?
巧了,你背過的八股文我也背過,現在我們來溫習一下我們背過的八股文。
什麼時候使用線程池呢?
比如一個請求要經過若干個服務獲取數據,且這些數據沒有先後依賴,最終需要把這些數據組合起來,一併返回,這樣經典的場景:
用戶點商品詳情,你要等半天才展示給用戶,那用戶肯定罵罵咧咧的久走了。
這個時候,八股文上是怎麼說的:用線程池來把串行的動作改成並行。
這個場景也是增加了服務 A 的吞吐量,但是用線程池就是非常正確的,沒有任何毛病。
但是你想想,我們最開始的這個案例,是這個場景嗎?
我們最開始的案例是想要在業務邏輯中增加一個線程池,對着一個下游服務就是一頓猛攻,不是所謂的串行改並行,而是用更多的線程,帶來更多的串行。
這已經不是一個概念了。
還有一種場景下,使用線程池也是合理的。
比如你有一個定時任務,要從數據庫中撈出狀態爲初始化的數據,然後去調用另外一個服務的接口查詢數據的最終狀態。
如果你的業務代碼是這樣的:
//獲取訂單狀態爲初始化的數據(0:初始化 1:處理中 2:成功 3:失敗)
//select * from order where order_status=0;
ArrayList initOrderInfoList = queryInitOrderInfoList();
//循環處理這批數據
for(OrderInfo orderInfo : initOrderInfoList){
//捕獲異常以免一條數據錯誤導致循環結束
try{
//發起rpc調用
String orderStatus = queryOrderStatus(orderInfo.getOrderId);
//更新訂單狀態
updateOrderInfo(orderInfo.getOrderId,orderStatus);
} catch (Exception e){
//打印異常
}
}
雖然你框架中使用了線程池,但是你就是在一個 for 循環中不停的去調用下游服務查詢數據狀態,是一條數據一條數據的進行處理,所以其實同一時間,只是使用了框架的線程池中的一個線程。
爲了更加快速的處理完這批數據,這個時候,你就可以懟一個線程池放在 for 循環裏面了:
//循環處理這批數據
for(OrderInfo orderInfo : initOrderInfoList){
//使用線程池
executor.execute(() -> {
//捕獲異常以免一條數據錯誤導致循環結束
try {
//發起rpc調用
String orderStatus = queryOrderStatus(orderInfo.getOrderId);
//更新訂單狀態
updateOrderInfo(orderInfo.getOrderId, orderStatus);
} catch (Exception e) {
//打印異常
}
});
}
需要注意的是,這個線程池的參數怎麼去合理的設置,是需要考慮的事情。
同時這個線程池的定位,就類似於 web 容器線程池的定位。
或者這樣對比起來看更加清晰一點:
定時任務觸發的時候,在發起遠程接口調用之前,沒有線程池,所以我們可以啓用一個線程池來加快數據的處理。
而 Http 調用或者 RPC 調用,框架中本來就已經有一個線程池了,而且也給你提供了對應的性能調優參數配置,那麼首先考慮的應該是把這個線程池充分利用起來。
如果僅僅是因爲異步化之後可以提升服務響應速度,沒有達到串行改並行的效果,那麼我更加建議使用消息隊列。
好了,本文的技術部分就到這裏啦。
下面這個環節叫做[荒腔走板],技術文章後面我偶爾會記錄、分享點生活相關的事情,和技術毫無關係。我知道看起來很突兀,但是我喜歡,因爲這是一個普通博主的生活氣息。
荒腔走板
不知道你看完文章之後,有沒有產生一個小疑問:最開始部分的 Demo 似乎用處並不大?
是的,我最開始構思的行文結構是是基於 Demo 在源碼中找到關於線程池的部分,從而引出其實有一些我們“看不見的線程池”的存在的。
原本週六我是有一整天的時間來寫這篇文章,甚至週五晚上還特意把 Demo 搞定,自己調試了一番,該打的斷點全部打上,並寫完 Demo 那部分之後,我纔去睡覺的,想得是第二天早上起來直接就能用。
剛好 Max 同學休年假,就回老家了,週日纔回來,所以整個週六我一個人在家。
按照慣例週六睡個懶覺的,早上 11 點才起牀,自己慢條斯理的做了一頓午飯,喫完飯已經是下午 1 點多了。
本來想着在沙發上躺一會,結果一躺就是一整個下午。期間也想過起來寫一會文章,坐在電腦前又飛快的躺回到沙發上,就是覺得這個事情索然無味,當下的那一刻就想躺着,然後無意識的刷手機,原本是拿來寫文章中關於源碼的部分的時間就這樣浪費了。
像極了高中時的我,週末帶大量作業回家,準備來個懸樑刺股,彎道超車,結果變成了一睡一天,捏緊剎車。
高中的時候,時間浪費了是真的可惜。
現在,不一樣了。
荒腔走板這張圖片,就是我躺在沙發上的時候,別人問我在幹什麼時隨手拍的一張。
我並不爲躺了一下午沒有幹正事而感到慚愧,浪費了的時間,纔是屬於自己的時間。
很久以前我看到別人在做一些浪費時間的事情的時候,我心裏可能會嘀咕幾句,勸人惜時。
這兩年我不會了,允許自己做自己,允許別人做別人。