真正理解 Node.js 的事件循環

原文=> What you should know to really understand the Node.js Event Loop

Node.js 是一個基於事件的平臺。這就意味着在Node中發生的全部事情都是對事件的反應。在 Node 中調用是經過一系列回調完成的。

在開發者看來，這一切都由一個名爲 libuv 的庫處理，它提供了一種稱爲事件循環的機制。

事件循環機制也許是在整個環境中最被誤解的概念

常見的誤解

誤解1：時間循環和用戶代碼跑在不一樣的線程當中

緣由：用戶的代碼跑在主線程中，事件循環則在另一個線程，每次執行回調，主線程將工做交給事件循環完成，而後事件循環將 ping 主線程進行回調

真實的：只有一個線程在執行 JS 代碼，這個線程就是事件循環運行的線程。
執行回調（知道正在運行的node.js應用程序中的每一個用戶級代碼都是回調）由事件循環完成。咱們稍後會深刻討論這一點。

誤解2：全部異步事件都由線程池處理

緣由：異步操做（如使用文件系統）執行出站 HTTP 請求或與數據庫交談始終加載到由 libuv 提供的線程池。

真實的：默認狀況下，libuv建立一個包含四個線程的線程池，以將異步工做分流。現在的操做系統已經爲許多I / O任務提供了異步接口（例如 Linux 的 aio）。只要有可能，libuv就會使用這些異步接口，避免使用線程池。這一樣適用於數據庫等第三方子系統。在這裏，驅動程序的做者寧願使用異步接口，而不使用線程池。簡而言之：只有在沒有其餘方式時，線程池纔會用於異步I / O。

誤解3：事件循環就像堆棧或者隊列同樣

緣由：事件循環不斷在遍歷一系列異步任務，並在任務完成時執行回調

真實的：雖然涉及到隊列式結構，但事件循環不會貫穿並處理堆棧。事件循環做爲一個過程是一組階段，其中包含以循環方式處理的特定任務。

瞭解事件循環的生命週期

要真正瞭解事件循環，應該清楚各個工做分別在那個階段完成了任務。下圖將會展現事件循環是如何工做的

具體請前往 => The Node.js Event Loop, Timers, and process.nextTick() | Node.js

計時器

經過 setTimeout() 或 setInterval() 計劃的全部內容都將在此處理。

IO 回調

在這裏全部的回調都會被處理。因爲 node 中全部業務代碼都是基於回調的。（例如，對傳入http請求的回調觸發級聯回調），所以這是處理業務代碼的階段。

IO 輪詢

投票處理下一次處理的新事件

當即設置

運行經過 setImmediate() 註冊的全部回調

關閉

執行全部的 (‘close’) 回調

工做處理延遲

此度量標準測量線程池處理異步任務須要多長時間。高工做時間處理延遲代表繁忙/耗盡的線程池。