并發模型
常見的并發模型是并行工作者模型，任務分配給多個工作者，每個工作者完成整個任務，常說的 C 語言的多線程就是這種模型，它的工作模式如下圖。
而 Node.js 用的并發模型是事件驅動模型，工作者對出現的事件做出反應，自身也能產生事件，它的工作模式如下圖。
單線程、同異步
常說的 JavaScript 的單線程指的是用戶代碼執行上的單線程，即同一時間只能執行一段代碼，這與 ?C 語言同一時間可以并行執行多段代碼形成鮮明的對比。
所以 Node.js 的執行可以簡單地分成兩個階段：
- 初始化代碼執行
- 事件循環
初始化代碼執行里，執行所有的同步操作代碼。所謂同步操作，就是永遠一步步執行、沒有結果不繼續執行后面代碼的操作。對應的異步操作是不等待結果就繼續執行后面代碼的操作。一般異步操作都帶有一個回調函數，而回調函數里的操作不包括在上面說的「后面代碼」里，而是異步操作完成以后希望要執行的操作，它們需要排隊等待被執行。
異步操作的回調函數排隊等待被執行就算在事件循環這一階段。在執行完所有同步代碼以后，Node.js 查看回調隊列里有沒有任務，有的話就執行，沒有的話就等待異步操作完成，因為帶有回調任務的異步操作完成時會將回調任務入隊到回調隊列，這樣就有任務可以執行了。所以可以很自然地推理出，如果回調隊列為空且沒有需要等待完成的異步操作，這個 Node.js 進程就結束了。事實也是如此。
由上也可以知道，所有的用戶代碼最終都是在同一線程也就是主線程上面順序執行的。而回調函數就是執行順序不是按聲明順序來執行而是要經過 Node.js 的事件循環來安排執行的用戶代碼。
Node.js 異步操作的執行
我們知道 Node.js 的所有異步操作都是由 Libuv 來負責的。Libuv 將可以給系統內核來執行的異步操作都交給了系統內核來執行，只有當系統不能執行這個操作的時候才會用自己的線程池來執行這個異步操作。下圖列出了一些異步操作一般由誰來執行：（圖來自：Morning Keynote- Everything You Need to Know About Node.js Event Loop - Bert Belder, IBM）
事件循環順序
如上圖，每一個方框代表一個事件循環階段，每一階段都有自己的先進先出的任務隊列。從用戶代碼入口開始，執行完所有同步代碼后進入事件循環，在事件循環里的每一個階段都查看該階段的任務隊列是否為空，如果不為空則嘗試同步執行（以先進先出順序一個一個執行）所有隊列里的任務直到隊列為空。這里輪詢事件階段的任務執行有最大次數限制。之后會細講。
實際上事件循環里包含的階段比圖上列出的多，但是我們應該關心的都在圖上列出來了。
setTimeout、setInterval
由 setTimeout 、setInterval 調度的回調任務在這里排隊執行。
I/O
像是由網絡、磁盤數據、子進程等 I/O 類調度的回調任務在這里排隊執行。
輪詢事件
查看是否有新的 I/O 事件，為下個輪詢的 I/O 階段提供任務。
如果所有隊列為空，這里阻塞主線程進入沉睡，直到發生以下事件之一：
- 有新的 I/O 事件發生
- 有子線程完成任務
- 有定時器達到閾值
也就是說，上面的事件的發生都會進入這階段的事件任務隊列，當事件隊列不為空時就執行到空或達到最大次數限制（因為這階段在處理事件的時候可以產生新事件入隊而導致隊列一直不為空從而阻塞事件循環，所以有最大次數限制）。
setImmediate
通過 setImmediate 設置的回調在這里排隊執行。
'close' 事件
on('close') 事件調用的回調在這里排隊執行。
setTimeout/setImmediate
對于在非 I/O 回調里的 setTimeout 和 setImmediate 來說，執行的先后順序無法確定，而在 I/O 回調里 setImmediate 總是比 setTimeout 先執行。
如在主模塊里的這段代碼：
setTimeout(() => {
console.log('in setTimeout')
}, 0)
setImmediate(() => {
console.log('in setImmediate')
})
運行結果可能是：
in setTimeout
in setImmediate
也可能是：
in setImmediate
in setTimeout
而下面這段代碼：
const fs = require('fs');
fs.readFile(filename, () => {
setTimeout(() => {
console.log('timeout');
}, 0);
setImmediate(() => {
console.log('immediate');
});
});
setImmediate 在 setTimeout 之前。
特殊的 process.nextTick() 和 Promise.resolve()
process.nextTick() 和 Promise.resolve() 不在上面的循環圖里的階段里面，它們也有一個自己的任務隊列，在每個階段結束的時候都會查看這個隊列是否為空，如果不為空就一個個執行里面所有的任務直到隊列為空。
執行邏輯大概如下圖：
顯然在遞歸調用 process.nextTick() 或 Promise.resolve() 的時候任務隊列一直不為空則會引起阻塞，但是它們的存在又確實是必要的：
- 用戶要在事件循環繼續之前處理錯誤、清理資源
- 在當前執行棧之后且在事件循環之前需要執行一個回調
官方文檔舉了這樣一個例子：
const EventEmitter = require('events');
const util = require('util');
function MyEmitter() {
EventEmitter.call(this);
this.emit('event'); // 這里對 `event` 事件的監聽還沒運行到，則這個 emit 不能觸發對應的回調
}
util.inherits(MyEmitter, EventEmitter);
const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
console.log('an event occurred!');
});
用了 process.nextTick() 后：
const EventEmitter = require('events');
const util = require('util');
function MyEmitter() {
EventEmitter.call(this);
// 先執行了所有同步代碼然后才執行 process.nextTick 的回調即 emit 一個 event 事件
process.nextTick(() => {
this.emit('event');
});
}
util.inherits(MyEmitter, EventEmitter);
const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
console.log('an event occurred!');
});
參考：
并發模型
The Node.js Event Loop, Timers, and process.nextTick()
What you should know to really understand the Node.js Event Loop
Morning Keynote- Everything You Need to Know About Node.js Event Loop - Bert Belder, IBM
Understanding the Node.js Event Loop
