摘要：單線程的話，如果我們做一些的操作比如說這是一個耗時的操所那么在這將近一秒內，線程就會被阻塞，無法繼續執行下面的任務。事件循環的主要機制就是任務隊列機制一個事件循環有一個或者多個任務隊列。

網上一搜事件循環, 很多文章標題的前面會加上 JavaScript, 但是我覺得事件循環機制跟 JavaScript 沒什么關系, JavaScript 只是一門解釋型語言, 方便開發和理解的, 由V8 JIT將 JavaScript 編譯成機器語言來調用底層, 至于瀏覽器怎么執行 JavaScript 代碼, JavaScript 管不著也不關心. 因此, “JavaScript事件循環機制”這種說法是不合理的. 事件循環機制是由運行時環境實現的, 具體來說有瀏覽器、Node等. 這篇文章就先來說說瀏覽器中實現的事件循環機制.

首先，javascript 在瀏覽器端運行是單線程的，這是由瀏覽器決定的，這是為了避免多線程執行不同任務會發生沖突的情況。也就是說我們寫的javascript 代碼只在一個線程上運行，稱之為主線程（HTML5提供了web worker API可以讓瀏覽器開一個線程運行比較復雜耗時的 javascript任務，但是這個線程仍受主線程的控制）。單線程的話，如果我們做一些“sleep”的操作比如說：

var now = + new Date()
while (+new Date() <= now + 1000){
//這是一個耗時的操所
}

那么在這將近一秒內，線程就會被阻塞，無法繼續執行下面的任務。

還有些操作比如說獲取遠程數據、I/O操作等，他們都很耗時，如果采用同步的方式，那么進程在執行這些操作時就會因為耗時而等待，就像上面那樣，下面的任務也只能等待，這樣效率并不高。

那瀏覽器是怎么做的呢?

我們找到WHATWG規范對Event loop的介紹:

為了協調事件，用戶交互，腳本，渲染，網絡等，用戶代理必須使用事件循環。

事件循環的主要機制就是任務隊列機制:

一個事件循環有一個或者多個任務隊列（task queues）。任務隊列是task的有序列表，task是調度Events，Parsing，Callbacks，Using a resource，Reacting to DOM manipulation這些任務的算法;

每個任務都來自一個特定的任務源（task source）(比如鼠標鍵盤事件)。來自同一個特定任務源且屬于特定事件循環的任務必須被加入到同一個任務隊列中，來自不同任務源的任務可以放在不同的任務隊列中;

瀏覽器調用這些隊列中的任務時采取這樣的做法: 相同隊列中的任務按照先進先出的順序, 不同的隊列按照提前設置的隊列優先級來調用. 例如，用戶代理可以有一個用于鼠標和鍵盤事件的任務隊列（用戶交互任務源），另一個用于其他任務。然后，用戶代理75%概率調用鍵盤和鼠標事件任務隊列，25%調用其他隊列, 這樣的話就保持界面響應而且不會餓死其他任務隊列. 但是相同隊列中的任務要按照先進先出的順序。也就是說多帶帶的任務隊列中的任務總是按先進先出的順序執行，但是不保證多個任務隊列中的任務優先級，具體實現可能會交叉執行

在調用任務的過程中, 會產生新的任務, 瀏覽器就會不斷執行任務, 因此稱為事件循環.

microtask queue 微任務隊列

還有一些特殊任務, 它們不會被放在task queues中, 會放在一個叫做microtask(微任務) queue中, 繼續看標準:

Each event loop has a microtask queue. A microtask is a task that is originally to be queued on the microtask queue rather than a task queue.

任務隊列可以有多個, 但是微任務隊列只有一個.

那么哪些任務是放在task queue, 哪些放在microtask queue呢? 通常對瀏覽器和Node.js來說:

macrotask(宏任務): script（整體代碼）, setTimeout, setInterval, setImmediate, I/O, UI rendering等

microtask(微任務): process.nextTick, Promises（這里指瀏覽器實現的原生 Promise）, Object.observe, MutationObserver等

請尤其注意macrotask中執行整體代碼也是一個宏任務

事件循環處理過程

總體來說, 瀏覽器端事件循環的一個回合(go-around或者叫cycle)就是:

從macrotask隊列中(task queue)取一個宏任務執行, 執行完后, 取出所有的microtask執行.

重復回合

無論在執行macrotask還是microtask, 都有可能產生新的macrotask或者microtask, 就這樣繼續執行.

用任務隊列機制解釋異步操作順序

這里有一些常見異步操作:

const interval = setInterval(() => {
  console.log("setInterval")
}, 0)

setTimeout(() => {  
  console.log("setTimeout 1")
  Promise.resolve().then(() => {
    console.log("promise 3")
  }).then(() => {
    console.log("promise 4")
  }).then(() => {
    setTimeout(() => {
      console.log("setTimeout 2")
      Promise.resolve().then(() => {
        console.log("promise 5")
      }).then(() => {
        console.log("promise 6")
      }).then(() => {
          clearInterval(interval)
      })
    }, 0)
  })
}, 0)

Promise.resolve().then(() => {
  console.log("promise 1")
}).then(() => {
  console.log("promise 2")
})

結果(Chrome 63.0.3239.84; Mac OS):

promise 1
promise 2
setInterval
setTimeout 1
promise 3
promise 4
setInterval // 大部分情況下2次, 少數情況下一次
setTimeout 2
promise 5
promise 6

這個順序是如何得來的?

我們先講promise 4后面只出現一次setInterval的情況, 畫個圖簡單表示一下這個過程:

注意
本圖為了方便把各時間段(Cycle)隊列的任務都畫在隊列中去了, 實際上執行一個task 和 microtask 后就會把這個任務從相應隊列中刪除

首先, 主任務就是執行腳本, 也就是執行上述代碼, 這也是一個task. 在執行代碼過程中, 遇到setTimeout、setInterval 就會將回調函數添加到task queue中, 遇到 promise 就會將then回調添加到 microtask 中去.

Task執行完, 接著取所有 microtask 執行, 所有microtask 執行完了, microtask queue也就空了, 接著再取task執行, 如果microtask queue為空, 沒有任務, 則繼續取下一個task執行, 就這樣循環執行. 圖中箭頭就表示執行的順序.

那么為什么promise 4后面大部分情況下出現2次setInterval, 少數情況出現1次呢?

我猜測這是因為setInterval是有最短間隔時間的(chrome下4ms左右), 這個時間不同機子、不同瀏覽器都有可能不一樣. 代碼中的參數是0, 意味著盡可能短的時間內就會產生一個task加入到 task queue中. 瀏覽器在執行setInterval后到執行下一個task前, 時間間隔就可能超過這個最短時間, 因此會產生一個setInterval task.

我是這樣論證的:

我把含有promise5、promise6回調函數的setTimeout的時間設置大一點, 讓它推遲插入task queue中:

...  
setTimeout(() => {
      console.log("setTimeout 2")
      Promise.resolve().then(() => {
        console.log("promise 5")
      }).then(() => {
        console.log("promise 6")
      }).then(() => {
          clearInterval(interval)
      })
}, 10)   //這里加上10ms 
...

結果是promise 4后面的setInterval出現了5次, 因此我覺得promise 4后面大部分情況下出現2次setInterval、少數情況出現一次的原因就是瀏覽器在執行setInterval回調函數后、執行setTimeout回調函數前, 時間間隔大部分情況超過了這個最短時間.

另外, 我試著再依次加上1ms, 直到14ms——也就是加上4ms時, promise 4后面的setInterval變成了6次, 可以認為setInterval最短間隔時間在Chrome下約為4ms(不考慮機子性能、設置).

Node中的奇怪結果

首先說明一下, 在Node中也體現了任務隊列的機制, 但是這不是Node實現的, 這是V8實現的, 由Node調用了V8任務隊列機制的API. 至于為什么是V8實現的, 我們翻翻ECMA 262 標準對 Job 和 Job queue 的介紹就可以得知

但是讓人摸不著頭腦的是, 這段代碼在node v8.5.0下有時會出現這樣的結果:

promise 1
promise 2
setInterval
setTimeout 1
promise 3
promise 4
setInterval
setTimeout 2
setInterval   // 為什么會出現setInterval???
promise 5
promise 6

按理說應該是setTimeout 2 => promise 5 => promise 6, 因為輸出setTimeout 2的回調函數是task, 執行完這個task后應該調用microtask 輸出promise 5 => promise 6啊? 很奇怪! Node對V8確實有些改動, 不知道是不是這方面原因...

還請大神解惑!

總結一下:

學習技術還是有捷徑的, 那就是讀標準 ;)