《大前端進階 Node.js》系列 異步非阻塞（同步/異步/阻塞/非阻塞/read/select/epoll）

前言

Coding 應當是一輩子的事業，而不只僅是 30 歲的青春飯
本文已收錄 GitHub https://github.com/ponkans/F2E，歡迎 Star，持續更新

面試官問：阻塞是用來形容什麼的？

若是你還要再三思考這個問題（面試官此時內心絕壁在想，這 tm 還要思考，還跟我談什麼 Node 異步非阻塞！），請好好看下面的文章。

---

每篇文章都但願你能收穫到東西，這篇是講 Node 異步非阻塞的原理，看完但願你有這些收穫：

• 阻塞、非阻塞本質與區別
• 同步、異步本質與區別
• Node 異步非阻塞本質

PS：底層基礎決定上層建築，請小夥伴們重視基礎哦~

---

異步非阻塞

在提到 Node 的時候，異步非阻塞是一個常常被說起的話題，與之伴隨的還有事件、回調、消息等等一系列詞語。

看這些概念就像追一個渣女，你好像以爲本身很懂她，但有時候你又會以爲一無所知。

本文將帶你們層層剖析，自底向上的深刻理解這些概念，讓你看清這個渣女的真面目。

阻塞非阻塞

不少人會把非阻塞和異步混淆，這兩個概念自己也確實有類似之處，但本質上確定是不同的，否則就不會被分紅兩個名詞了。

咱們先要思考的是阻塞是用來形容什麼的？答案天然是進程。進程的五大狀態：建立、就緒、運行、阻塞、終止。因此咱們講的阻塞非阻塞，必定是指進程。

明確了這一點以後，咱們再來看這個概念，當一個進程在發起一個調用的時候，若是這個進程從運行態變成阻塞態，那就說明這是一次阻塞調用，反之就是非阻塞。

同步與異步

咱們先搞清楚同步異步形容的是啥？咱們常說的是某某方法是個異步方法，或者是某某調用是一種異步調用。可見同步異步形容的是某個調用的特性。

何爲同步？就是在發出一個功能調用時，在沒有獲得結果以前，該調用就不會返回。按照這個定義，其實絕大多數函數都是同步調用。

異步的概念和同步相對。當一個異步功能調用發出後，調用者不能馬上獲得結果。當該異步功能完成後，經過狀態、通知或回調來通知調用者。

這裏有兩個重要的點：

• 第一是能夠在獲得結果前就直接返回，無需調用阻塞線程等待。
• 第二就是可以在結束前主動的去通知主線程，並執行回調。

對於上述解釋，可能有的小夥伴仍是會有點迷茫，難以理清楚兩者關係。彆着急，往下看。

響水壺

關於上面的概念，網上有一個很經典的響水壺解釋，怪怪在這裏引伸給你們，並談談本身的理解。

---

隔壁王大爺（不是隔壁老王，hhhhh~~）有個水壺，王大爺常常用它來燒開水。

王大爺把水壺放到火上燒，而後啥也不幹在那等，直到水開了王大爺再去搞別的事情。（同步阻塞）

王大爺以爲本身有點憨，不打算等了。把水壺放上去以後大爺就是去看電視，是否是來瞅一眼有沒有開（同步非阻塞）

王大爺去買了個響水壺，他把響水壺放在火上，而後也是等着水開，水開的時候水壺會發出聲響（異步阻塞）

王大爺又以爲本身有點憨，他把響水壺放在火上而後去看電視，這時他不用是否是來瞅一眼，由於水開的時候水壺會發出聲音通知大爺。（異步非阻塞）

上面四個栗子裏，阻塞非阻塞說明的是大爺的狀態，同步非同步說明的是水壺的調用姿式。水壺能在燒好的時候主動響起，就等同於咱們異步的定義，能在結束時通知主線程而且回調。因此異步通常配合非阻塞，才能發揮其做用。

阻塞 IO 與 非阻塞 IO

有了上面王大爺的啓發，你們對一些基本的概念或許有了認知，那咱們來進一步討論下非阻塞 IO 與異步 IO。

阻塞 IO

阻塞 IO 如同其名字，主線程會在調用 IO 方法時進入阻塞態，直到 IO 結果返回，再繼續運行，至關於須要整個操做所有結束了，調用纔會返回。

首先要知道讀一個磁盤的開銷，讀磁盤涉及到磁盤尋道，在對應扇區讀取數據，而後把數據放在內存等一系列操做。因此阻塞 IO 必然是會被取代的，具體能夠看下面這張圖。

阻塞IO

非阻塞 IO

非阻塞 IO 的特色與阻塞相對，在操做系統發起 IO 調用以後，能夠先不帶數據直接返回，這樣主線程不會被阻塞，而後操做系統來處理讀磁盤這一系列操做，而不須要主進程被阻塞，這就是咱們所說的非阻塞 IO 了。

---

這裏能夠順便提一下，如今大多數 IO 設備都支持DMA(Direct Memory Access，直接存儲器訪問)，DMA 的意義在於能夠解放 IO 時處理器的壓力，CPU 只須要 DMA 控制器初始化，並向 I/O 接口發出操做命令，I/O 接口提出 DMA 請求，而後在存儲器和外部設備之間直接進行數據傳送，在傳送過程當中不須要中央處理器的參與，這段時間 CPU 能夠去執行別的任務。

---

回到咱們的非阻塞 IO，他的好處顯而易見，進程不用等待函數返回，能夠作作別的事情。

但也有一個明顯的缺陷，咱們想要讀取的時候在函數返回時並無就位。我的的理解是，若是你接下來的操做立刻就強依賴 IO 的數據，那阻塞與否並沒有區別。

若是你接下來的操做並不是強依賴，那能夠先把非強依賴的程序執行了，再去看 IO 有沒有好，這樣 cpu 等待 IO 這段時間就能夠被利用起來。非阻塞 IO 大體過程以下圖。

PS：這裏的阻塞和非阻塞和以前的觀點一致，看的是發起調用的進程有沒有阻塞。

非阻塞IO

輪詢技術演進

上面講到了一個關鍵的點，非阻塞 IO 的時候，咱們想要讀取的時候在函數返回時並無就位。

就像那個燒水的大爺，在他沒有響水壺的時候，他雖然一邊燒水一邊看電視，但他是否是也要去看一下水到底有沒有開。

我這裏也同樣，咱們沒法預知數據何時好，因此咱們也要去主動的探查 IO 數據是否就位，由於是咱們主動的探查，那能夠肯定的就是，輪詢技術並不是異步，他並非一個響水壺。

---

這裏須要幫你們梳理清楚一個細節，可能你們常常能聽到不少 IO 相關的名詞，好比 recv，select, epoll, kqueue 等等，但對他們可能沒有很直觀的認知。咱們要讀取一個文件，是分爲兩步的。

首先是去讀取文件，而後是獲取讀取的結果。

讀取文件須要調用的是 recv，recv 能夠根據參數來決定是否阻塞，咱們所討論的非阻塞 IO，只是在讀取這一步，而 select、epoll 都是第二步（獲取結果）作的事情，他們是阻塞的方法。你們切莫把兩個步奏混爲一談。

結下來咱們來捋一下咱們的輪詢技術。

初代：read

read 是最原始的輪詢方式，read 自己就是讀取文件的方法，在 C++的調用裏面，若是設置了 NONBLCOK 屬性，那就會當即返回，但返回的值是-1。

簡單寫了個 C 的 read 供你們參考，加深下理解。先是阻塞 read。

阻塞IO

那麼以後咱們須要這個 IO 結果的時候咋辦呢？只能不斷的調用 read 方法，直到他的返回不是-1 爲止，而後從傳入的一個 char[] 中拿文件數據，代碼大體以下圖。

非阻塞IO

流程大體以下圖，雖然在發起 IO 的時候非阻塞了，但其弊端顯而易見，他須要在獲取的時候不斷的去輪詢，這裏會很耗費 cpu，若是這是一個多核機器可能還好，若是是單核，那一個 cpu 被這些沒有意義的輪詢耗在這裏，就很憨（怕不是個鐵憨憨吧）。

非阻塞IO

進階：select

以前咱們講了 read，read 的弊端是很明顯的，須要不斷輪詢，除此以外咱們只能監聽一個文件，好比我須要讀兩個文件，那意味着我會調用兩次 read 方法，這個時候我想獲取結果的話就須要先輪詢一個，等那個返回了，再輪詢另外一個。

你可能會說，我在一個 while(True)裏面寫兩個不斷調用 read 的代碼不就好了。

那咱們若是要讀 10 個文件？100 個文件？你要寫 100 個嗎？答案確定是 NO。針對不斷的空輪詢問題，和多文件監聽問題，操做系統給出了更優的解決方案，select 調用。

咱們在發起 read 操做以後，能拿到一個 fd（文件描述符），對文件描述符不理解的小夥伴能夠去翻一下怪怪以前寫的《大前端進階 Node.js》系列 多進程模型底層實現，裏面有詳細描述。

若是咱們發起 100 次 read 調用，那就會有 100 個 fd，select 能夠批量監聽文件描述符，咱們在調用 select 方法的時候，當前進程進入阻塞狀態（注意，以前講的非阻塞 IO 是 read 調用，select 是阻塞調用）。

當監聽的這一批文件描述符裏，有屬於某個文件描述符的 IO 操做結束的時候，操做系統會發起中斷，中斷程序作的事情很簡單，喚醒阻塞的進程。

這個時候意味着某個文件描述符的數據已經就緒了，但問題是哪個呢？母雞。咋辦呢？輪詢。把全部監聽的 fd 掃一遍，取出就緒的文件描述符，讀取響應數據。

這樣的話，以前兩個問題就獲得瞭解決，輪詢消耗 cpu 問題經過阻塞進程，中斷喚醒來解決，多文件監聽問題經過 select 的多句柄監聽特性來搞定。

大體流程以下圖。

演進：epoll

select 解決了大多數的問題，但卻帶來了新的問題，如上面描述的同樣，進程在被喚醒的時候一臉迷茫，是誰喚醒的我？？他要一個一個看。

若是文件過多，這種遍歷對性能的影響是很大的，因此 select 設計之初便規定監聽的文件描述符是有上限的，通常是 1024 個。

爲了解決 select 留下的坑，誕生了咱們如今用的最普遍的 epoll。

epoll 最關鍵的優化點在於，引入了一個介於進程和 fd 之間的東西：eventpoll。

在有 IO 結束的時候，中斷程序不是直接喚醒進程，而是會先把 IO 就緒的文件描述符放在 eventpoll 裏面，後續在進程被喚醒後，不須要輪詢整個 fd 列表，只須要在 eventpoll 裏面拿就緒的文件描述符便可。

以上就是目前主流輪詢技術的演進過程了~

下期預告，Node 之異步非阻塞 IO（下）

以前講過，read 提供了非阻塞的 IO 調用方式，但系統在須要數據的時候，須要主動去獲取，而不是異步的被通知，epoll 再美好，終究不是一個響水壺。

那是否是沒有響水壺的存在呢？倒也不是，Linux 提供了 AIO 模式，是基於信號和回調的原生異步接口，但不幸的是這玩意只有 Linux 有，並且存在必定的缺陷（這裏不展開講了，有興趣能夠留言，日後安排一期來說）。

本文一開始就說了，異步非阻塞是 Node 的特性，它騙人？不，咱們上面討論的各類觀點都是基於單進程來討論的，若是利用其多進程，雖然操做系統層面不支持響水壺，Node 能夠本身來作一個。

eventloop + 線程池

如我上面的小標題，實現異步非阻塞 IO 的原理就是 eventloop+線程池。Node 在不一樣的平臺會對應不一樣的系統調用，但不管如何，基本的架構大同小異。

具體的 Node 異步非阻塞 IO 架構，敬請期待怪怪的《大前端進階 Node.js》系列 異步非阻塞（下）。

總結

本文已收錄 GitHub https://github.com/ponkans/F2E，歡迎 Star，持續更新

這篇是基礎，必要要先掌握，後面的理解起來纔會有如魚得水的感受~

這篇文章裏，怪怪主要幫你們捋清了不少容易混淆的概念，並從操做系統的角度介紹了咱們目前 IO 的情況。總結下就是：

• 阻塞非阻塞看進程狀態。
• 異步非異步看調用的特性。
• read 是同步非阻塞，能夠看做是非阻塞 IO，但獲取結果數據的方法是一種同步阻塞的方法，經常使用的就是上面講的 epoll。

PS：看過網上部分文章，都沒講在點上，理解這個東西須要從最初，最本質去理解它，你纔會真正的懂這個架構！

那 Node 如何異步非阻塞？eventLoop 究竟是個啥？留到本系列（下）來說。

近期原創傳送門,biubiubiu：

• 《吐血整理》系列 大廠前端組件庫工具集合（PC 端、移動端、JS、CSS 等）
• 《大前端進階 Node.js》系列 P6 必備腳手架/CI 構建能力（上）
• 《大前端 基礎組件》系列 80 行實現一個網頁水印 npm 包
• 《大前端進階 安全》系列 HTTPS 詳解》

---

喜歡的小夥伴加個關注，點個贊哦，感恩💕😊

聯繫我 / 公衆號

微信搜索【接水怪】或掃描下面二維碼回覆」加羣「，我會拉你進技術交流羣。講真的，在這個羣，哪怕您不說話，光看聊天記錄也是一種成長。（阿里技術專家、敖丙做者、Java3y、蘑菇街資深前端、螞蟻金服安全專家、各路大牛都在）。

接水怪也會按期原創，按期跟小夥伴進行經驗交流或幫忙看簡歷。加關注，不迷路，有機會一塊兒跑個步🏃 ↓↓↓