Node.js Event loop 監控器。高的 frequency 和低的持續時間是最理想的 event loop 狀態。

上圖顯示三點半到五點半之間，event loop 的 frequency 驟降，然後 duration 居高不下。

Node.js 是一個基於事件的平臺。 這意味著在 Node 中發生的一切都是對事件的反應。通過 Node 的事務會遍歷級聯的回撥(a cascade of callbacks)。

這一切都由一個名為 libuv 的庫處理，它提供了一種稱為事件迴圈的機制。

關於 Node.js 的事件迴圈，有很多誤解。

誤解1：事件迴圈機制執行在獨立於使用者邏輯的單獨執行緒內

誤解：

有一個主執行緒，使用者的 JavaScript 程式碼（userland 程式碼）在其中執行，另一個主執行緒執行事件迴圈。 每次發生非同步操作時，主執行緒都會將工作交給事件迴圈執行緒，一旦完成，事件迴圈執行緒就會通知主執行緒執行回撥。

正確的理解：

只有一個執行緒執行 JavaScript 程式碼，這是執行事件迴圈的執行緒。 回撥的執行（執行中的 Node.js 應用程式中的每個使用者空間程式碼都是回撥）由事件迴圈完成。

誤解2：非同步操作通過執行緒池完成

非同步操作，如使用檔案系統、執行出站 HTTP 請求或與資料庫對話，總是載入到 libuv 提供的執行緒池中。

正確的理解：

Libuv 預設建立一個包含四個執行緒的執行緒池來解除安裝非同步工作。 今天的作業系統已經為許多 I/O 任務提供了非同步介面（例如 Linux 上的 AIO）。
只要有可能，libuv 就會使用那些非同步介面，避免使用執行緒池。

這同樣適用於第三方子系統，如資料庫。 這裡驅動程式的作者寧願使用非同步介面也不願使用執行緒池。

簡而言之：只有在沒有其他辦法的情況下，才會使用執行緒池進行非同步I/O.

誤解3：Event Loop 利用了棧或者佇列的資料結構

事件迴圈不斷遍歷非同步任務的 FIFO，並在任務完成時執行回撥。

正確的理解：

雖然涉及到類似佇列的結構，但事件迴圈不會遍歷並處理堆疊。 作為一個程序的事件迴圈是一組具有特定任務的階段，這些階段以迴圈方式處理。