大家都知道BIO非常的低效，而網(wǎng)絡(luò)編程中的IO多路復(fù)用普遍比較高效。

現(xiàn)在，io_uring已經(jīng)能夠挑戰(zhàn)NIO的，功能非常強(qiáng)大。io_uring在2019加入了Linux內(nèi)核，目前5.1+的內(nèi)核，可以采用這個(gè)功能。

隨著一步步的優(yōu)化，系統(tǒng)調(diào)用這個(gè)大家伙，調(diào)用次數(shù)越來(lái)越少了。

一、性能耗費(fèi)在哪里？

在Linux的性能指標(biāo)里，有us和sy?兩個(gè)指標(biāo)，使用top命令可以很方便的看到。

us?是用戶進(jìn)程的意思，而sy是在內(nèi)核中所使用的cpu占比。如果進(jìn)程在內(nèi)核態(tài)和用戶態(tài)切換的非常頻繁，那么效率大部分就會(huì)浪費(fèi)在切換之上。

一次內(nèi)核態(tài)和用戶態(tài)切換的時(shí)間，普遍在微秒級(jí)別以上，可以說(shuō)非常昂貴了。

cpu的性能是固定的，在無(wú)用的東西上浪費(fèi)越小，在真正業(yè)務(wù)上的處理就效率越高。影響效率的有兩個(gè)方面。

1. 進(jìn)程或者線程的數(shù)量，引起過(guò)多的上下文切換。進(jìn)程是由內(nèi)核來(lái)管理和調(diào)度的，進(jìn)程的切換只能發(fā)生在內(nèi)核態(tài)。所以，如果你的代碼切換了線程，它必然伴隨著一次用戶態(tài)和內(nèi)核態(tài)的切換。
2. IO的編程模型，引起過(guò)多的系統(tǒng)態(tài)和內(nèi)核態(tài)切換。比如同步阻塞等待的模型，需要經(jīng)過(guò)數(shù)據(jù)接收、軟中斷的處理（內(nèi)核態(tài)），然后喚醒用戶線程（用戶態(tài)），處理完畢之后再進(jìn)入等待狀態(tài)（內(nèi)核態(tài)）。

關(guān)于mmap，可以參考這篇文章。

《OS近距離：mmap給你想要的快！》

二、BIO

可以說(shuō)，BIO這種模式，在線程數(shù)量上爆炸，編程模型古老，把性能低的原因全給占了。

通常情況下，BIO一條連接就對(duì)應(yīng)著一個(gè)線程。BIO的讀寫(xiě)操作是阻塞的，線程的整個(gè)生命周期和連接的生命周期是一樣的，而且不能夠被復(fù)用。

如果連接有1000條，那就需要1000個(gè)線程。線程資源是非常昂貴的，除了占用大量的內(nèi)存，還會(huì)占用非常多的CPU調(diào)度時(shí)間，所以BIO在連接非常多的情況下，效率會(huì)變得非常低。

BIO的編程模型，也存在諸多缺陷。因?yàn)樗亲枞跃幊棠Ｊ?，在有?shù)據(jù)的時(shí)候，需要內(nèi)核通知它；在沒(méi)有數(shù)據(jù)的時(shí)候，需要阻塞wait在相應(yīng)的socket上。這兩個(gè)操作，都涉及到內(nèi)核態(tài)和用戶態(tài)的切換。如果數(shù)據(jù)報(bào)文非常頻繁，BIO就需要這么一直切換。

三、NIO

提到NIO，Java中使用的是Epoll，Netty使用的是改良后的Epoll，它們都是多路復(fù)用，只不過(guò)叫慣了，所以稱作NIO。

采用Reactor編程模型，可以采用非常少的線程，就能夠應(yīng)對(duì)海量的Socket連接。

一旦有新的事件到達(dá)，比如有新的連接到來(lái)，主線程就能夠被調(diào)度到，程序就能夠向下執(zhí)行。這時(shí)候，就能夠根據(jù)訂閱的事件通知，持續(xù)獲取訂閱的事件。

NIO是基于事件機(jī)制的，有一個(gè)叫做Selector的選擇器，阻塞獲取關(guān)注的事件列表。獲取到事件列表后，可以通過(guò)分發(fā)器，進(jìn)行真正的數(shù)據(jù)操作。

熟悉Netty的同學(xué)可以看到，這個(gè)模型就是Netty設(shè)計(jì)的基礎(chǔ)。在Netty中，Boss線程對(duì)應(yīng)著對(duì)連接的處理和分派，相當(dāng)于mainReactor；Work線程 對(duì)應(yīng)著subReactor，使用多線程負(fù)責(zé)讀寫(xiě)事件的分發(fā)和處理。

通過(guò)Selector選擇器，NIO將BIO中頻繁的wait和notify操作，集中在了一起，大量的減少了內(nèi)核態(tài)和用戶態(tài)的切換。在網(wǎng)絡(luò)流量比較高的時(shí)候，Selector甚至都不會(huì)阻塞，它將一直處于處理數(shù)據(jù)的過(guò)程中。

這種模式將每個(gè)組件的職責(zé)分的更細(xì)，耦合度也更低，能有效的解決C10k問(wèn)題。

四、io_uring

但是，NIO依然有大量的系統(tǒng)調(diào)用，那就是Epoll的epoll_ctl。另外，獲取到網(wǎng)絡(luò)事件之后，還需要把socket的數(shù)據(jù)進(jìn)行存取，這也是一次系統(tǒng)調(diào)用。雖然相對(duì)于BIO來(lái)說(shuō)，上下文切換次數(shù)已經(jīng)減少很多，但它仍然花費(fèi)了比較多的時(shí)間在切換之上。

IO只負(fù)責(zé)對(duì)發(fā)生在fd描述符上的事件進(jìn)行通知。事件的獲取和通知部分是非阻塞的，但收到通知之后的操作，卻是阻塞的。即使使用多線程去處理這些事件，它依然是阻塞的。

如果能把這些系統(tǒng)調(diào)用都放在操作系統(tǒng)里完成，那么就可以節(jié)省下這些系統(tǒng)調(diào)用的時(shí)間，io_uring就是干這個(gè)的。

如圖，用戶態(tài)和內(nèi)核態(tài)共享提交隊(duì)列（submission queue）和完成隊(duì)列（completion queue），這兩條隊(duì)列通過(guò)mmap共享，高效且安全。

（SQ）給內(nèi)核源源不斷的布置任務(wù)，然后從另外一條隊(duì)列（CQ）獲取結(jié)果；內(nèi)核則按需進(jìn)行 epoll()，并在一個(gè)線程池中執(zhí)行就緒的任務(wù)。

用戶態(tài)支持Polling模式，不會(huì)發(fā)生中斷，也就沒(méi)有系統(tǒng)調(diào)用，通過(guò)輪詢即可消費(fèi)事件；內(nèi)核態(tài)也支持Polling模式，同樣不會(huì)發(fā)生上下文切換。

可以看出關(guān)鍵的設(shè)計(jì)在于，內(nèi)核通過(guò)一塊和用戶共享的內(nèi)存區(qū)域進(jìn)行消息的傳遞，可以繞過(guò)Linux 的 syscall 機(jī)制。

rocksdb、ceph等應(yīng)用，已經(jīng)在嘗試這些功能，隨著內(nèi)核io_uring的成熟，相信網(wǎng)絡(luò)編程在效率上會(huì)更上一層樓。

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