一. JavaScript是單線程的
為什么呢 ? 首先JavaScript語言的一大特點就是單線程, 通俗點說就是, 同一個時間只能做一件事.那么會又有新的問題, JavaScript為什么不能有多個線程呢 ?
JavaScript最初被設計用在瀏覽器中, 那么設想下, 瀏覽器中的JavaScript是多線程的.例如 : 假定JavaScript同時有兩個線程, 一個線程在某個DOM節點上添加內容, 另外一個線程刪除了這個節點, 這時瀏覽器應該以哪個線程為準呢 ?
后來, HTML5提出Web Worker標準, 允許JavaScript腳本創建多個線程, 但是子線程完全受主線程控制, 且不得操作DOM, 所以, 這個新標準并沒有改變JavaScript單線程本質
二. JavaScript為什么需要異步 ?
如果JavaScript中不存在異步, 只能自上而下執行, 如果上一行解析時間很長, 那么下面的代碼就會被阻塞.對于用戶而言, 阻塞就意味著 "卡死", 這樣就導致了很差的用戶體驗.所以, JavaScript中存在異步執行
三. 那么又是如何實現異步的呢 ?
任務隊列 :1. 所有同步任務都在主線程上執行, 形成一個執行棧(stack)。2.主線程之外, 還存在一個任務隊列Event Loop, 異步任務在event table中注冊函數, 當滿足觸發條件(即DOM，AJAX，setTimeout，setImmediate有返回結果了) 后, 被推入任務隊列(Event Loop)。3. 一旦執行棧(stack) 中所有同步任務都執行完了, 系統就會讀取任務隊列(Event Loop), 看看里面有哪些事件.那些對應的異步任務, 于是結束等待狀態, 進入執行棧, 開始執行 。4.主線程不斷重復上面的第三步。
例子1：
console.log(1)
setTimeout(
function() {
console.log(2)
},
0)
console.log(3)
運行的結果是：1，3，2
代碼分析：
1.console.log(1)是同步任務，放入主線程里
2.setTimeout是異步任務，被放入event table，0秒之后被推入任務隊列(Event Loop)里
3.console.log(3)是同步任務，放到主線程里.
當1，3在控制臺被打印后，主線程去Event Loop(事件隊列)里查看是否有可執行的函數，執行setTimeout里的函數，這就是Event Loop
四.Event Loop是什么 ?
主線程從任務隊列(Event Loop) 中讀取事件, 這個過程是循環不斷的, 所以整個的這種運行機制又稱為Event Loop(事件循環).
上圖中, 主線程運行的時候, 產生堆(heap) 和棧(stack), 棧中的代碼調用各種外部API， 它們在” 任務隊列(Event Loop)” 中加入各種事件（ click， load， done）。 只要棧中的代碼執行完畢， 主線程就會去讀取” 任務隊列(Event Loop)”， 依次執行那些事件所對應的回調函數。
例子2：
setTimeout(function() {
console.log('定時器開始啦')
});
new Promise(function(resolve) {
console.log('馬上執行for循環啦');
for(var i =0; i <10000; i++) {
i ==99 &&resolve();
}
}).then(function() {
console.log('執行then函數啦')
});
console.log('代碼執行結束');
嘗試按照，上文我們剛學到的js執行機制去分析：
1.setTimeout 是異步任務，被放到event table
2.new Promise是同步任務，被放到主線程里，直接執行打印console.log('馬上執行for循環啦');
3..then里的函數是異步任務，被放到event table
4.console.log('代碼執行結束');是同步代碼，被放到主線程里，直接執行
所以根據分析的結果是：馬上執行for循環啦---代碼執行結束---定時器開始啦---執行then函數啦
自己運行了下代碼后，結果居然不是這樣的，而是：
馬上執行for循環啦---代碼執行結束---執行then函數啦---定時器開始啦
事實上，按照異步和同步的方式來劃分，并不準確，而準確的劃分方式是：
macro-task(宏任務)：script(整體代碼), setTimeout, setInterval, setImmediate, I/O, UI rendering。
micro-task(微任務)：process.nextTick, Promise, Object.observe(已廢棄), MutationObserver(html5新特性)
按照這種分類方式，js的執行機制是：
1.執行一個宏任務，過程中如果遇到微任務，就將其放到微任務的"事件隊列"里
2.當前宏任務執行完成后，會查看微任務的"事件隊列"，并將里面全部的微任務依次執行完
3.重復以上2步驟，結合圖1和圖2就是更為準確的js執行機制了
那么，去分析例2:
1.首先執行script下的宏任務，遇到setTimeout,將其放到宏任務的“隊列”里
2.遇到 new Promise直接執行，打印"馬上執行for循環啦"
3.遇到then方法，是微任務，將其放到微任務的“隊列”里。
4.遇到console.log('代碼執行結束');是同步任務，直接打印"代碼執行結束"
5.本輪宏任務執行完畢，查看本輪的微任務，發現有一個then方法里的函數，打印"執行then函數啦"
6.到此,本輪的event loop 全部完成。
7.下一輪的循環里，先執行一個宏任務，發現宏任務的“隊列”里有一個setTimeout里的函數,執行打印"定時器開始啦"
所以最后的執行順序是： 馬上執行for循環啦---代碼執行結束---執行then函數啦---定時器開始啦
五.定時器setTimeout()和setInterval()
定時器指定某些代碼在多少時間之后執行這叫做”定時器”（timer）功能，也就是定時執行的代碼。
例子3：
setTimeout(function(){
console.log('執行了')
},3000)
我們一般會說：3秒后，會執行setTimeout里的那個函數，但是這種說法并不嚴謹，準確的解釋是：3秒后，setTimeout里的函數會被推入事件隊列(Event Loop)，而事件隊列(Event Loop)里的任務，只有在主線程空閑時才會執行，所以條件只有同時滿足(ps:3秒后并且主線程空閑)時，才會3秒后執行函數
如果主線程執行內容很多，執行時間超過3秒，比如主線程里執行棧執行了10秒，那么這個函數只能10秒后執行了
六.Node.js的Event Loop
Node.js也是單線程的Event Loop，但是它的運行機制不同于瀏覽器環境。
如圖所示，Node.js的運行機制如下：
1.V8引擎解析JavaScript腳本。
2.解析后的代碼，調用Node API。
3.libuv庫負責Node API的執行。它將不同的任務分配給不同的線程，形成一個Event Loop（事件循環），以異步的方式將任務的執行結果返回給V8引擎。
4.V8引擎再將結果返回給用戶。
除了setTimeout和setInterval這兩個方法，Node.js還提供了另外兩個與”任務隊列”有關的方法：process.nextTick和setImmediate。它們可以幫助我們加深對”任務隊列”的理解。
nextTick setImmediate 區別和聯系
nextTick :把回調函數放在當前執行棧的底部,而多個process.nextTick語句總是在當前”執行棧”一次執行完
setImmediate :把回調函數放在事件隊列(event loop)的尾部,而多個setImmediate可能則需要多次loop才能執行完
例子4：
process.nextTick(function A() {
console.log(1);
process.nextTick(function B(){console.log(2);});
});
setTimeout(function timeout() {
console.log('TIMEOUT FIRED');
}, 0)
上面代碼中，由于process.nextTick方法指定的回調函數，總是在當前”執行棧”的尾部觸發，所以不僅回調函數A比setTimeout指定的回調函數timeout先執行，而且函數B也比timeout先執行。這說明，如果有多個process.nextTick語句（不管它們是否嵌套），將全部在當前”執行棧”執行。所以結果是：1，2，'TIMEOUT FIRED'
現在，再來看看setImmediate
例子5：
setImmediate(function A() {
console.log(1);
setImmediate(function B(){
console.log(2);
});
});
setTimeout(function timeout() {
console.log('TIMEOUT FIRED');
}, 0);
上面代碼中，setImmediate與setTimeout(fn,0)各自添加了一個回調函數A和timeout，都是在下一次事件隊列(Event Loop)觸發。那么，哪個回調函數先執行呢？答案是不確定。運行結果可能是1,TIMEOUT FIRED,2，也可能是TIMEOUT FIRED,1,2。
令人困惑的是，Node.js文檔中稱，setImmediate指定的回調函數，總是排在setTimeout前面。實際上，這種情況只發生在遞歸調用的時候。
例子6：
setImmediate(function (){
setImmediate(function A() {
console.log(1);
setImmediate(function B(){console.log(2);});
});
setTimeout(function timeout() {
console.log('TIMEOUT FIRED');
}, 0);
});
上面代碼中，setImmediate和setTimeout被封裝在一個setImmediate里面，它的運行結果總是1，TIMEOUT FIRED，2，這時函數A一定在timeout前面觸發。至于2排在TIMEOUT FIRED的后面（即函數B在timeout后面觸發），是因為setImmediate總是將事件注冊到下一輪事件隊列(Event Loop)，所以函數A和timeout是在同一輪Loop執行，而函數B在下一輪Loop執行
另外，由于process.nextTick指定的回調函數是在本次”事件循環”觸發，而setImmediate指定的是在下次”事件循環”觸發，所以很顯然，前者總是比后者發生得早，而且執行效率也高（因為不用檢查”任務隊列”）。
