本文首發于我的博客，這是我的github，歡迎star。
在網上找了很多事件循環和任務隊列相關的文章，有些說的不是很清楚，看完感覺還是有些暈暈乎乎，所以寫這篇博客把整體思路梳理一下。如果你有什么不同的理解，或是疑惑的地方，可以留言討論。這里是我的github，歡迎來訪。
事件循環與任務隊列是
JS中比較重要的兩個概念。這兩個概念在ES5和ES6兩個標準中有不同的實現。尤其在ES6標準中，清楚的區分宏觀任務隊列和微觀任務隊列才能解釋Promise一些看似奇怪的表現。
事件循環
事件循環是什么？為什么要有事件循環這個東西？我們都知道JS是單線程的，但是像Ajax，或是DOM事件這種很耗時的操作，需要用并發處理，否則單線程會長時間等待，什么也做不了。而單線程循環就是并發的一種形式，一個線程中只有一個事件循環。而任務隊列是用來配合事件循環完成操作的，一個線程可以擁有多個任務隊列。
任務隊列
任務隊列是什么？故名思意，排著任務的隊列。所謂任務是WebAPIs返回的一個個通知，讓JS主線程在讀取任務隊列的時候得知這個異步任務已經完成，下一步該執行這個任務的回調函數了。主線程擁有多個任務隊列，不同的任務隊列用來排列來自不同任務源的任務。任務源是什么？像setTimeout/Promise/DOM事件等都是任務源，來自同類任務源的任務我們稱它們是同源的，比如setTimeout與setInterval就是同源的。在ES6標準中任務隊列又分為宏觀任務隊列和微觀任務隊列，我們后邊再詳細討論。
下面先通俗的講述一下ES5中事件循環到底是怎么循環的，如圖（據阮一峰前輩的教程）：
圖中有三大塊：
- 函數調用棧：即執行棧。
- WebAPIs：瀏覽器的接口。比如一個
Ajax操作，主線程會把收發Ajax交給瀏覽器的API，之后就繼續做別的事情，瀏覽器在接收到Ajax返回的數據之后，會把一個Ajax完成的事件排到相應的任務隊列后邊。 - 任務隊列們：主線程中有多個任務隊列，同源的任務排在屬于自己的任務隊列。
一個具體點的栗子。比如現在打開了一個頁面，里邊有一段<script>，其中有Ajax，DOM操作等等。這段JS是在瀏覽器提供的全局環境（瀏覽器中是window）里執行的，執行中遇到函數調用時會壓入執行棧。
- 主線程在遇到
Ajax或是setTimeout這種異步操作時會交給瀏覽器的WebAPIs，然后繼續執行后邊的代碼，直到最后執行棧為空。 - 瀏覽器會在不確定的時間將完成的任務返回，排到相應的任務隊列后。
- 執行棧為空后，主線程會到任務隊列中去取任務，這些任務會告訴下一步應該執行哪些回調函數。任務隊列是具有優先級的，按照優先級決定訪問的先后順序。而優先級在不同的環境中會有所不同，所以不能給出一個固定的優先級。
- 每訪問一個隊列，執行棧會執行完這個任務隊列的所有的代碼，然后再取下一個任務隊列需要執行的的代碼。如果在執行中遇到了當前屬于任務隊列的異步任務時。此次任務的返回不會直接排到當前任務隊列之后。因為這屬于兩次不同的事件循環，會被區分開來。
就這樣循環執行，直到三大塊全為空，這稱為事件循環。
微觀任務隊列
ES6標準中任務隊列存在兩種類型，一種就是上邊提到的一些隊列，比如setTimeout、網絡請求Ajax、用戶I\O等都屬于宏觀任務隊列（macrotask queue），另一種是微觀任務隊列（microtask queue），Promise就屬于微觀任務隊列。
??添加了微觀任務隊列之后事件循環有什么變化呢？在執行棧執行的過程中會把屬于微觀任務隊列的任務分配到相應的微觀任務隊列中去。而在調用棧執行空之后，主線程讀取任務隊列時，會先讀取所有微觀任務隊列，然后讀取一個宏觀任務隊列，再讀取所有的微觀任務隊列。如圖：
好了，說了很多概念上的東西，不如一段代碼來的清晰：
setTimeout(function(){console.log(4)},0);
new Promise(function(resolve){
console.log(1)
for( var i=0 ; i<10000 ; i++ ){
i==9999 && resolve()
}
console.log(2)
}).then(function(){
console.log(5)
});
console.log(3);
- 腳本開始執行，最先遇到
setTimeout，交給瀏覽器去計時，達到setTimeout限制最短計時之后，把這個任務推入setTimeout隊列。 - 遇到
Promise構造函數，構造函數參數執行，輸出1，調用resolve改變Promise對象的狀態，然后輸出2。 -
Promise對象調用then方法，將這個任務推入Promise任務隊列。 - 執行
console.log(3)，輸出3。 - 調用棧為空，讀取任務隊列，按照
讀取所有微觀任務隊列 -> 執行 ->
讀取一個宏觀任務隊列 -> 執行 ->
讀取所有微觀任務隊列 -> 執行 ->
再讀取一個宏觀任務隊列...的順序。 - 讀取所有微觀任務隊列中的任務，執行這些任務指定的回調函數。執行
then指定的回調函數，輸出5（微觀任務隊列也具有優先級）。 - 最后讀取到
setTimeout的任務，執行回調函數，輸出4。
所以最后的輸出順序是1,2,3,5,4，而不是1,2,3,4,5。如果不清楚微觀任務隊列的執行機制，很容易將兩個異步任務歸為一類，將執行順序判斷錯誤。
到這里算是把事件循環和任務隊列說的比較清楚了，參考了很多大佬的博客與討論：
http://www.ruanyifeng.com/blog/2014/10/event-loop.html
https://www.zhihu.com/question/36972010
http://www.lxweimin.com/p/12b9f73c5a4f
http://www.cnblogs.com/hity-tt/p/6733062.html
如果你有不同的理解請到博客下方留言，這是我的github，歡迎來訪，你的star就是我的動力。
