[[401711]]

【51CTO.com快譯】由于JavaScript是單線程的，那么在瀏覽器中，為了在等待動作完成時不會阻塞主線程的異步代碼處理，JavaScript使用事件循環在調用堆棧、Web API和回調隊列之間，持續協調代碼的執行。不過，由Node.js自行實現的Node.js事件循環，雖然與之有著許多相同的模式，但是由于Node.js不與DOM交互，且可以處理各種輸入和輸出(I/O)，因此它在工作方式上卻有所不同。

在本文中，我們將先了解Node.js事件循環背后的理論，再探究幾個使用setTimeout、setImmediate和process.nextTick的示例。最后，我們將部分工作代碼部署到Heroku(這一種快速部署應用的簡便方法，請參閱--https://www.heroku.com/)中，以查看其運行情況。

Node.js的事件循環

總的說來，Node.js事件循環可以協調計時器、回調、以及I/O事件等操作與執行。這便是Node.js在單線程的情況下，處理異步行為的方式。如下事件循環圖，很好地展示了其執行的順序。

如您所見，Node.js事件循環共有六個主要階段，它們分別是：

• 計時器(Timers)：那些由setTimeout和setInterval安排的回調，會在此階段被執行。
• 待處理的回調(Pending callbacks)：那些被推遲到下一個循環迭代的I/O回調，會在此階段被執行。
• 空閑，準備(Idle, prepare)：此階段僅由Node.js內部所使用。
• 輪詢(Poll)：此階段用于檢索新的I/O事件，并執行I/O回調(不過那些由計時器和setImmediate安排的回調，以及下面將提到的關閉回調除外，畢竟它們會在其他不同的階段被處理)。
• 檢查(Check)：由setImmediate安排的回調會在該階段被執行。
• 關閉回調(Close callbacks)：此階段主要執行諸如銷毀套接字連接等回調。

您可能會好奇，為何process.nextTick并未在上述任何階段被提到?其實，這是因為：作為一種特殊的方法，就技術而言，它并非Node.js事件循環的一部分。相反，無論process.nextTick方法在何時被調用，它都會將自己的回調放入隊列之中，然后“無論事件循環當前處于哪個階段，都會在完成當前操作后，處理排隊中的各種回調”(源自：Node.js事件循環文檔)。

事件循環的場景示例

也許您覺得上文針對Node.js事件循環的每個階段的解釋，過于抽象了。那么，我在Heroku上創建了一個包含了各種可運行代碼段示例的演示應用，請參見--https://nodejs-event-loop-demo.herokuapp.com/。在該應用中，單擊任何示例按鈕，都會向服務器端發送一個API請求。而Node.js會在后端執行所選示例的代碼片段，然后通過API將相應的響應返回給前端。您可以從GitHub的鏈接處，查看到完整的代碼。

讓我們通過如下示例，來更好地理解Node.js事件循環的調用順序。

示例1

讓我們從如下簡單的示例開始(如下圖所示)：

示例1-同步代碼

在此，我們有三個功能函數。由于它們是同步的，因此代碼會從上至下順次執行。也就是說，如果三個函數的調用順序為：first、second、third，它們的代碼也會以相同的順序去執行：first、second、third。

示例2

接下來，我們會在第二個示例中引入setTimeout的概念(如下圖所示)：

示例2-setTimeout

在此，我們先調用first函數，然后在延遲0毫秒后計劃調用帶有setTimeout的second函數，最后調用third函數。那么，這些函數的執行順序就變成了：first、third、second。您一定會好奇：為什么second函數會被最后執行呢?

下面讓我們來理解兩個重要的原則。首先，使用帶有延遲值的setTimeout方法，并不意味著應用將在指定毫秒數后，立即執行回調函數。實際上，該值表示的是：執行回調之前，需要經過的最短時間。其次，使用setTimeout來為回調設定的后期執行時間，會在事件循環的每一次迭代期間中始終執行該規則。因此，在事件循環的第一次迭代中，first函數被執行，second函數被“安排”(scheduled)，third函數再被執行。然而，在事件循環的第二次迭代期間中，0毫秒的最小延遲已被滿足，因此second函數便會在第二次迭代的“計時器”階段被執行。

示例3

然后，我們會在第三個示例中引入setImmediate的概念(如下圖所示)：

示例3-setImmediate與setTimeout

在該示例中，我們執行first函數，使用setTimeout來為second函數延遲0毫秒，然后使用setImmediate來“安排”third函數。那么，在代碼執行的過程中，就會出現一個問題：到底是哪種類型的安排優先?setTimeout還是setImmediate?

鑒于前面已經討論過setTimeout的工作機制，我們來簡單介紹一下setImmediate方法。該方法在事件循環的下一次迭代的“檢查”階段，會去執行其回調函數。因此，如果setImmediate在事件循環的第一次迭代期間被調用，那么它的回調方法會被“安排”上，并在事件循環的第二次迭代期間，執行該回調方法。

正如你在輸出中所看到的那樣，在我們的示例中，由于被setImmediate安排的回調先于被setTimeout安排的回調執行，因此該示例函數的執行順序為：first、third、second。

當然，由setImmediate和setTimeout安排的執行到底誰先誰后，實際上取決于被調用方法的上下文。當從Node.js腳本中的主模塊，直接調用這兩種方法時，其時間取決于進程的性能，因此在每次運行腳本時，回調都可以按照不同的順序被執行。不過，在I/O周期內調用這些方法時，setImmediate回調總是發生在setTimeout回調之前。在我們上述示例中，由于這些方法是作為響應API端點的某個部分被調用的，因此setImmediate回調會始終在setTimeout回調之前被執行。

示例4

為了實現快速的健全性檢查，我們使用setImmediate和setTimeout來構建另一個示例(如下圖所示)。

示例4-再次使用setImmediate與setTimeout

在此示例中，我們使用setImmediate來安排first函數，接著直接執行second函數，然后使用setTimeout的0毫秒延遲來安排third函數。您恐怕已經猜到了，上述函數的執行順序為：second、first、third。而在事件循環的第二次迭代中，second函數被setImmediate安排在該I/O周期內被執行，然后third函數在延遲0毫秒時間后也被執行了。

示例5

下面，我們將process.nextTick方法引入最后一個示例(如下圖所示)。

示例5-process.nextTick

在該示例中，我們使用setImmediate來安排first函數，并使用process.nextTick來安排second函數，再使用帶有0毫秒延遲的setTimeout來安排third函數，最后執行fourth函數。那么，在代碼運行后，整體的調用順序為：fourth、second、first、third。

有了前面的基礎，我們很容易理解fourth函數為何被首先執行了。畢竟它是被直接調用的，而無需通過任何其他方法來進行安排。process.nextTick方法安排了second函數在第二個被執行，first函數緊接其后。最后被執行的是third函數，其原因在于，在同一個I/O周期內，由setImmediate安排的回調會先于setTimeout安排的回調去執行。

那么，為什么由process.nextTick安排的second函數會先于由setImmediate安排的first函數被執行呢?請不要被這兩種方法的名稱所誤導，并非setImmediate就代表著回調一定會被立即執行，而process.nextTick就一定要等到事件循環的下一輪再執行回調。在此，我們并不展開討論，如果您有興趣的話，請參見https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick-vs-setimmediate。您只需注意的是：process.nextTick是在安排的同一階段中，立即執行回調的;而setImmediate的回調則是在事件循環的下一次迭代、或計時期間中被執行的。

小結

通過上述示例，您應該對Node.js的事件循環，以及諸如setTimeout、setImmediate和process.nextTick等方法有所了解了。當然，您不必深究Node.js的內部結構，以及處理命令的相關操作。我們完全可以將Node.js視為一個黑匣子，輕松地用好Node.js事件循環的各項調用順序即可。為了進一步了解上面提到的各種示例，您可以通過鏈接—https://nodejs-event-loop-demo.herokuapp.com/來查看其demo應用，或者通過鏈接—https://github.com/thawkin3/nodejs-event-loop-demo查看它們在GitHub上的代碼。您甚至可以通過參考--https://heroku.com/deploy?template=https://github.com/thawkin3/nodejs-event-loop-demo，將代碼部署到Heroku處。

原文標題：Understanding the Node.js Event Loop，作者: Tyler Hawkins

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】