2018-03-23 星期五 農曆 二月初七戊戌年 【狗年】乙卯月 甲寅日
宜： 裁衣、經絡、伐木、開柱眼、拆卸、修造、動土、上樑、合脊、合壽木、入殮、除服、成服、移柩、破土
忌： 祭祀、嫁娶、出行、上樑、掘井
本文采用 自問自答的形式 配合程式碼（執行結果）來講解 event loop 的執行機制
執行環境 : node.js-8.10.0 WebStorm 2017.2.3
example 1
console.log(1);
console.log(2);
setTimeout(function(){
console.log(3)
})
setTimeout(function(){
console.log(4);
})
console.log(5)複製程式碼執行：輸入結果 顯示如下
現在我們來例項分析下 這個程式碼執行結果為什麼是這樣的 ：
Node是基於單執行緒的(主要主執行緒是單執行緒，用來執行同步任務。等遇到非同步任務的時候，會呼叫另外一條非同步執行緒來處理非同步任務，如：setTimeout 這些會影響主執行緒執行的，需要等待一段時間)
程式碼執行分析 如下： 主執行緒開始執行，自上往下，先是開始執行同步任務， 依次執行
console.log(1)
console.log(2)
複製程式碼然後遇到 非同步任務
setTimeout(function(){
console.log(3)
})
setTimeout(function(){
console.log(4);
})複製程式碼這時候 Node 會把 這些非同步任務 push 到一個 非同步執行棧 stack 裡面
然後繼續執行 主執行緒的 任務
console.log(5) 複製程式碼等到所有的同步任務任務，這時候 Node 開始執行 非同步佇列 棧 stack 裡面的非同步任務
按照 堆 stack 的特徵 先進後出的特徵 會依次開始執行 棧裡面的非同步任務
等待他們執行完畢以後，會生成一個 巨集 任務佇列（下面會有詳細的介紹），按照執行前後順序來新增到這個佇列中，
佇列遵循先進先出的規則，開始依次執行 列隊
執行結果如下：
3
4複製程式碼現在來更深入的瞭解下 Node.js event loop 機制
當Node.js啟動時會初始化event loop, 每一個event loop都會包含按如下順序六個迴圈階段，
┌───────────────────────┐
┌─>│ timers │
│ └──────────┬────────────┘
│ ┌──────────┴────────────┐
│ │ I/O callbacks │
│ └──────────┬────────────┘
│ ┌──────────┴────────────┐
│ │ idle, prepare │
│ └──────────┬────────────┘ ┌───────────────┐
│ ┌──────────┴────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └──────────┬────────────┘ │ data, etc. │
│ ┌──────────┴────────────┐ └───────────────┘
│ │ check │
│ └──────────┬────────────┘
│ ┌──────────┴────────────┐
└──┤ close callbacks │
└───────────────────────┘複製程式碼- timers 階段: 這個階段執行setTimeout(callback) and setInterval(callback)預定的callback;
- I/O callbacks 階段: 執行除了 close事件的callbacks、被timers(定時器，setTimeout、setInterval等)設定的callbacks、setImmediate()設定的callbacks之外的callbacks;
- idle, prepare 階段: 僅node內部使用;
- poll 階段: 獲取新的I/O事件, 適當的條件下node將阻塞在這裡;
- check 階段: 執行setImmediate() 設定的callbacks;
- close callbacks 階段: 比如socket.on(‘close’, callback)的callback會在這個階段執行.
每一個階段都有一個裝有callbacks的fifo queue(佇列)，當event loop執行到一個指定階段時， node將執行該階段的fifo queue(佇列)，當佇列callback執行完或者執行callbacks數量超過該階段的上限時， event loop會轉入下一下階段.
注意上面六個階段都不包括 process.nextTick() (稍後會在巨集任務和微任務)
example 2
setTimeout(() => {
console.log('setTimeout')
}, 0)
setImmediate(() => {
console.log('setImmediate')
})複製程式碼執行結果：
setImmediate
setTimeout
複製程式碼或者：
setTimeout
setImmediate
複製程式碼為什麼結果不確定呢？
解釋：setTimeout/setInterval 的第二個引數取值範圍是：[1, 2^31 - 1]，如果超過這個範圍則會初始化為 1，即 setTimeout(fn, 0) === setTimeout(fn, 1)。我們知道 setTimeout 的回撥函式在 timer 階段執行，setImmediate 的回撥函式在 check 階段執行，event loop 的開始會先檢查 timer 階段，但是在開始之前到 timer 階段會消耗一定時間，所以就會出現兩種情況：
- timer 前的準備時間超過 1ms，滿足 loop->time >= 1，則執行 timer 階段（setTimeout）的回撥函式
- timer 前的準備時間小於 1ms，則先執行 check 階段（setImmediate）的回撥函式，下一次 event loop 執行 timer 階段（setTimeout）的回撥函式
example 3
const fs = require('fs')
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('setTimeout')
}, 0)
setImmediate(() => {
console.log('setImmediate')
})
})
複製程式碼執行結果：
setImmediate
setTimeout
複製程式碼解釋：fs.readFile 的回撥函式執行完後：
- 註冊 setTimeout 的回撥函式到 timer 階段
- 註冊 setImmediate 的回撥函式到 check 階段
- event loop 從 pool 階段出來繼續往下一個階段執行，恰好是 check 階段，所以 setImmediate 的回撥函式先執行
- 本次 event loop 結束後，進入下一次 event loop，執行 setTimeout 的回撥函式
所以，在 I/O Callbacks 中註冊的 setTimeout 和 setImmediate，永遠都是 setImmediate 先執行。
巨集任務和微任務
這兩個概念屬於對非同步任務的分類，不同的API註冊的非同步任務會依次進入自身對應的佇列中，然後等待Event Loop將它們依次壓入執行棧中執行。
task主要包含：setTimeout、setInterval、setImmediate、I/O、UI互動事件
microtask主要包含：Promise、process.nextTick
microtask 會優先 task 執行
一般 Event loop 會先清空 microtask 佇列裡面的任務，然後才回去 執行 task 裡面的 非同步任務
example 4
console.log(1);
console.log(2);
setImmediate(function(){
console.log(4);
})
setTimeout(function(){
console.log(3)
})
process.nextTick(function(){
console.log('process.nextTick')
})
Promise.resolve().then(function () {
console.log('Promise')
})複製程式碼執行結果如下：
1
2
process.nextTick
Promise
3
4複製程式碼先依次執行同步任務 console.log 輸出
1
2複製程式碼然後開始執行非同步任務 stack 裡面的任務 先微任務在巨集任務
輸出
process.nextTick
Promise 複製程式碼最後等待微任務執行完畢以後，在執行最後的巨集任務
3
4複製程式碼待續。。。。。。