摘要：如果過程中遇到引擎執行會被掛起線程，更新保存在一個隊列中等待引擎空閑才執行引擎線程負責解析運行執行時間過程會導致頁面渲染加載阻塞事件觸發線程，瀏覽器用以控制事件循環。

總所周知，javascript是一門依賴宿主環境的單線程的弱腳本語言，這意味著什么？

javascript的運行環境一般都由宿主環境（如瀏覽器、Node、Ringo等）和執行環境（Javascript引擎V8，JavaScript Core等）共同構成；

弱類型定義語言：數據類型可以被忽略的語言。例如計算時會在不同類型之間進行隱式轉換；

在某一時刻內只能執行特定的一個任務，并且會阻塞其它任務執行；

本文主要講的就是第三點，從中引出下一個問題

Javascript當初誕生的目的其實就是因為當年網絡技術十分低效，如表單驗證等個幾十秒才能得到反饋的用戶體驗十分糟糕，為了給瀏覽器做些簡單處理以前由服務器端負責的一些表單驗證。被Netscape公司指派花了十天就負責設計出一門新語言的Javascript之父就是Brendan Eich。盡管他并不喜歡自己設計的這作品，就有了大家都聽過的一句話：

"與其說我愛Javascript，不如說我恨它。它是C語言和Self語言一夜情的產物。十八世紀英國文學家約翰遜博士說得好："它的優秀之處并非原創，它的原創之處并不優秀。"（the part that is good is not original, and the part that is original is not good.）"

作為瀏覽器腳本語言而誕生的JavaScript的主要用途是與用戶互動，以及操作DOM。這決定了它只需要是單線程就足以解決目的，否則會帶來很復雜的同步問題。但是沒想到的是之后的網絡越發的發達，這些年來的瀏覽器大戰為了爭奪地盤，反而讓Javascript被賦予了更多的職責跟可能性，今時今日的Javascript必須想方設法把自身的潛力激發出來，而單線程的弱點就被無限放大了，因為在阻塞任務的過程中不一定是因為CPU被占用了，而可能是因為I/O太慢（如AJAX請求，定時器任務，Dom事件交互等并不消耗CPU的等待造成資源時間浪費）。

我們一直都在說Javascript是單線程，但瀏覽器是多線程的，在內核控制下互相配合以保持同步，主要的常駐線程有：

GUI渲染線程：負責渲染界面，解析HTML，CSS，構建DOM和Render樹布局繪制等。如果過程中遇到JS引擎執行會被掛起線程，GUI更新保存在一個隊列中等待JS引擎空閑才執行；

JS引擎線程：負責解析運行Javascript；執行時間過程會導致頁面渲染加載阻塞；

事件觸發線程，瀏覽器用以控制事件循環。當JS引擎執行過程中觸發的事件（如點擊，請求等）會將對應任務添加到事件線程中，而當對應的事件符合觸發條件被觸發時會把對應任務添加到處理隊列的尾部等到JS引擎空閑時處理；

定時器觸發線程：因為JS引擎是單線程容易阻塞，所以需要有多帶帶線程為setTimeout和setInterval計時并觸發，同樣是符合觸發條件（記時完畢）被觸發時會把對應任務添加到處理隊列的尾部等到JS引擎空閑時處理；W3C標準規定時間間隔低于4ms被算為4ms。

異步http請求線程：XMLHttpRequest在連接后瀏覽器新開線程去請求，檢測到狀態變化如果有設置回調函數會產生狀態變更事件，然后把對應任務添加到處理隊列的尾部等到JS引擎空閑時處理；

好像鋪墊的有點多，往外偏了，接下來往回拉一點談談這些怎么運行的。

自己畫了一個丑丑的圖，大家將就看著吧。

function addOne(n) {
  var x = n + 1;
  return addTwo(x);
}

function addTwo(n) {
  return n + 2;
}

console.log(addOne(1)) //4;

以這個例子做說明。
當調用addOne時創建一個包含addOne入參和局部變量的幀并添加進去stack，當調用到addTwo時也同樣創建一個包含addTwo入參和局部變量的幀并添加進去在首部，執行完addTwo函數并返回時addTwo幀被移出stack，addOne執行完后addOne幀也被移除。
原理：當執行方法時都會建立自己的內存棧，在這個方法內定義的入參變量都會保存在棧內存里，執行結束后該方法的內存棧也將自然銷毀了。

一般來說，程序會劃分有兩種分配內存的空間 -- 堆（heap）和棧（stack）。

因為棧只能存放下確定大小的簡單數據，所以像變量（其實也就是一個記錄了指向復雜結構數據的地址指向，所以變量也是保存在棧里的）和基本類型Undefined、Null、Boolean、Number 和 String等是按值傳遞的都會保存在棧里，隨著方法執行完畢而被銷毀。
堆負責存放復雜結構的對象，數組，函數等創建成本較高并且可重用數據，即使方法執行完也不會被銷毀，直到系統的垃圾回收機制核實了沒有任何引用才會回收。
其實這只是棧的含義之一，Stack的三種含義

有時候我們代碼有問題導致棧堆溢出原因大概是這種情況：

好了，現在再看回上圖，除了heap和stack之外還有一個。。。

Javascript里分兩種隊列：

宏任務隊列（macro tasks）：事件循環中可以有多個macro tasks，每次循環只會提取一個，包括script（全局任務）, setTimeout, setInterval, setImmediate, I/O, UI rendering等.

微任務隊列（micro tasks）：事件循環中只有一個并且有優先級區別micro tasks，每次循環會提取多次直至隊列清空，包括process.nextTick, Promise, Object.observer, MutationObserver等.

console.log("log start!");
setTimeout(function () {
  console.log("setTimeout300");
}, 300)

Promise.resolve().then(function () {
  console.log("promise resolve");
}).then(function () {
  console.log("promise resolve then");
})

new Promise(function (resolve, reject) {
  console.log("promise pending");
  resolve();
}).then(function () {
  console.log("promise pending then");
})

setTimeout(function () {
  console.log("setTimeout0");
  Promise.resolve().then(function () {
    console.log("promise3 in setTimeout");
  })
}, 0)
console.log("log end!");

// log start!
// promise pending
// log end!
// promise resolve
// promise pending then
// promise resolve then
// setTimeout0
// promise3 in setTimeout
// setTimeout300

例子過程，具體分析下面再說。
第一次執行事件打印：log start!, promise pending, log end!， promise resolve，promise pending then，promise resolve then；
第二次執行事件打印：setTimeout0，promise3 in setTimeout；
第三次執行事件打印：setTimeout300；

下面終于開始走到正題了

我在上面鋪墊了這么多東西，大家大概都能有個初步印象，然后所謂的Event Loop就是把這些東西串聯起來的一種機制吧，因為這東西各有理解，比如兩位前端大牛之間就有分歧。
阮一峰：JavaScript 運行機制詳解：再談Event Loop
樸靈：樸靈評注
我看過他們很多的博客和書籍，對我幫助都很大，我就用自己的看法講講我眼中的Event Loop。

1，所有的任務都被放主線程上運行形成一個執行棧（execution context stack），其中的方法入參變量保存在棧內存中，復雜結構對象被保存在堆內存中；
2，同步任務直接執行并阻塞后續任務等待結束，其中遇到一些異步任務會新開線程去執行該任務（如上面提到的定時器觸發線程，異步http請求線程等）然后往下執行，異步任務執行完返回結果之后就把回調事件加入到任務隊列（Queue）；
3，當執行棧（execution context stack）所有任務執行完之后，會到任務隊列（Queue）里提取所有的微任務隊列（micro tasks）事件執行完；
4，一次循環結束，GUI渲染線程接管檢查，重新渲染界面；
5，執行棧（execution context stack）到宏任務隊列（macro tasks）提取一個事件到執行，接著主線程就一直重復第3步；

大概理解就這樣子，當然可能會有點偏差，歡迎指正！

我在上面線程說過

定時器觸發線程：因為JS引擎是單線程容易阻塞，所以需要有多帶帶線程為setTimeout和setInterval計時并觸發，同樣是符合觸發條件（記時完畢）被觸發時會把對應任務添加到處理隊列的尾部等到JS引擎空閑時處理；W3C標準規定時間間隔低于4ms被算為4ms。

里面有一些需要特別注意的地方：
1，計時完畢只是把對應任務添加到處理隊列，依然要等執行棧空閑才會去提取隊列執行，這個概念很重要，切記！即使設置0秒也不會立馬執行，因為W3C標準規定時間間隔低于4ms被算為4ms，具體看瀏覽器，我個人認為不管怎樣始終都會被放置到處理隊列等待處理；
2，setTimeout重復執行過程中每次時間誤差會影響后續執行時間，而setInterval是每次精確時間執行，當然這是指他們把對應任務添加到處理隊列的精確性；

但是setInterval也有一些問題：

累計效應，如果執行棧阻塞時間足夠長以至于隊列中已經存在多個setInterval的對應任務的情況，執行時間會遠低于開發者期望的結果；

部分瀏覽器（如Safari等）滾動過程不執行JS，容易造成卡頓和未知錯誤；

瀏覽器最小化顯示時setInterval會繼續執行，但是對應任務會等到瀏覽器還原再一瞬間全部執行；

坦白講，我原本時打算寫一篇關于異步編程的文章，然后在鋪墊前文的路上拉不回來了就變成了一篇梳理Javascript執行機制了，不過沒關系，理解這些也是很重要的