Node.js Event loop 監控器。高的 frequency 和低的持續時間是最理想的 event loop 狀態。
![](https://img-blog.csdnimg.cn/img_convert/8db071251fc84a27fb9d62babfb232a2.png)

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

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

這一切都由一個名為 [libuv](https://www.dynatrace.com/news/blog/all-you-need-to-know-to-really-understand-the-node-js-event-loop-and-its-metrics/) 的庫處理，它提供了一種稱為事件迴圈的機制。

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

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

誤解：

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

正確的理解：

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

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

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

正確的理解：

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

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

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

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

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

正確的理解：

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

Node.js Event Loop 的三大常見理解誤區和正確概念辨析

相關文章