I/O密集型業(yè)務(wù)，線程數(shù)量要設(shè)置成 CPU 的 2 倍！

也不知道這是哪本書的坑爹理論，現(xiàn)在總有一些小青年老拿著這樣的定理來說教。說的信誓旦旦，毋庸置疑，仿佛是權(quán)威的化身。討論時(shí)把這樣的理論當(dāng)作前提，真的是受害不淺。

但可惜的是，這樣的理論站不住腳。我只需要一個(gè)簡單的反問，它就不攻自破：

Tomcat的默認(rèn)線程數(shù)是多少呢？

它既不是 CPU 的 2 倍，也不是什么其他數(shù)值。在某些高并發(fā)的服務(wù)中，它的核心線程數(shù)，可能達(dá)到數(shù)千甚至上萬。對于一個(gè)Tomcat來說，它處理的大多數(shù)都是I/O密集型的業(yè)務(wù)，可以說是最好的實(shí)踐場景。

要明白這個(gè)線程數(shù)設(shè)置的玄機(jī)，就必須了解I/O請求的特點(diǎn)。I/O請求不僅僅指的是磁盤讀寫，在互聯(lián)網(wǎng)服務(wù)中更多指的是網(wǎng)絡(luò)I/O請求。

I/O請求的速度，要遠(yuǎn)低于CPU運(yùn)行的速度。大部分I/O請求，在發(fā)起之后，就進(jìn)入等待狀態(tài)，這個(gè)等待狀態(tài)不會(huì)浪費(fèi)CPU，所以一臺(tái)機(jī)器在同一時(shí)刻支持的I/O請求，可以很多。

如果I/O請求的速度比較快，和CPU的耗時(shí)對等的時(shí)候，我們把處理I/O的線程數(shù)，設(shè)置成 CPU 的 2倍，是合理的。但現(xiàn)實(shí)中并沒有這么多如果，我們要處理秒成千上萬的I/O請求，注定了它的耗時(shí)要比CPU多的多。

像RPC組件，比如Dubbo服務(wù)端，也會(huì)設(shè)置一個(gè)比較大的線程數(shù)（比如600）；Feign這種就更不用多說了，短連接意味著更多線程數(shù)的支持。這都是些最佳實(shí)踐。

雖然I/O線程數(shù)量增多，會(huì)造成非常頻繁的上下文切換，進(jìn)而影響效率。但在互聯(lián)網(wǎng)應(yīng)用中，它卻是一個(gè)優(yōu)秀的解決方案。

更優(yōu)秀的解決方式也有，那就是使用協(xié)程。協(xié)程是用戶態(tài)的線程，是對普通線程更細(xì)粒度的劃分。它是在用戶態(tài)運(yùn)行的，由用戶自行調(diào)度，所以也就避免了頻繁的上下文切換問題。

但協(xié)程在Java中還不成熟，它依然是Golang語言的誘人特性。使用Golang開發(fā)的Web服務(wù)，可以采用更少的線程來支持大量I/O密集型的請求。

綜上所述，標(biāo)題的表述并不正確，而且錯(cuò)的離譜。

作者簡介：小姐姐味道  (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。