瀏覽器中的事件循環機制

原文地址在我的博客, 轉載注明來源

網上一搜事件循環, 很多文章標題的前面會加上 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的介紹:

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確實有些改動, 不知道是不是這方面原因...

還請大神解惑!

你竟然讀到這了

總結一下:

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

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,197評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,415評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,104評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,884評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,647評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,130評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,208評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,366評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,887評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,737評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,939評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,478評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,174評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,586評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,827評論 1 283
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,608評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,914評論 2 372

推薦閱讀更多精彩內容