為什麼說IO密集型業務,執行緒數是CPU數的2倍?

張哥說技術發表於2023-01-04

為什麼說IO密集型業務,執行緒數是CPU數的2倍?

原創:小姐姐味道(微信公眾號ID:xjjdog),歡迎分享,非公眾號轉載保留此宣告。

I/O密集型業務,執行緒數量要設定成 CPU 的 2 倍!

也不知道這是哪本書的坑爹理論,現在總有一些小青年老拿著這樣的定理來說教。說的信誓旦旦,毋庸置疑,彷彿是權威的化身。討論時把這樣的理論當作前提,真的是受害不淺。

但可惜的是,這樣的理論站不住腳。我只需要一個簡單的反問,它就不攻自破:

Tomcat的預設執行緒數是多少呢?

為什麼說IO密集型業務,執行緒數是CPU數的2倍?

它既不是 CPU 的 2 倍,也不是什麼其他數值。在某些高併發的服務中,它的核心執行緒數,可能達到數千甚至上萬。對於一個Tomcat來說,它處理的大多數都是I/O密集型的業務,可以說是最好的實踐場景。

要明白這個執行緒數設定的玄機,就必須瞭解I/O請求的特點。I/O請求不僅僅指的是磁碟讀寫,在網際網路服務中更多指的是網路I/O請求。

I/O請求的速度,要遠低於CPU執行的速度。大部分I/O請求,在發起之後,就進入等待狀態,這個等待狀態不會浪費CPU,所以一臺機器在同一時刻支援的I/O請求,可以很多。

如果I/O請求的速度比較快,和CPU的耗時對等的時候,我們把處理I/O的執行緒數,設定成 CPU 的 2倍,是合理的。但現實中並沒有這麼多如果,我們要處理秒成千上萬的I/O請求,註定了它的耗時要比CPU多的多。

像RPC元件,比如Dubbo服務端,也會設定一個比較大的執行緒數(比如600);Feign這種就更不用多說了,短連線意味著更多執行緒數的支援。這都是些最佳實踐。

雖然I/O執行緒數量增多,會造成非常頻繁的上下文切換,進而影響效率。但在網際網路應用中,它卻是一個優秀的解決方案。

更優秀的解決方式也有,那就是使用協程。協程是使用者態的執行緒,是對普通執行緒更細粒度的劃分。它是在使用者態執行的,由使用者自行排程,所以也就避免了頻繁的上下文切換問題。

但協程在Java中還不成熟,它依然是Golang語言的誘人特性。使用Golang開發的Web服務,可以採用更少的執行緒來支援大量I/O密集型的請求。

綜上所述,標題的表述並不正確,而且錯的離譜。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024923/viewspace-2930749/,如需轉載,請註明出處,否則將追究法律責任。

相關文章