說起JS的異步執(zhí)行機制，如果百度一下，你首先會發(fā)現(xiàn)阮一峰的寫過一篇關于異步機制的文章（http://www.ruanyifeng.com/blog/2014/10/event-loop.html），等你津津有味又一頭霧水的看完，然后繼續(xù)看百度的其他結果，然后會發(fā)現(xiàn)，阮一峰的這篇被另一個大牛樸靈給批判了
（http://www.360doc.com/content/14/1011/13/15077656_416048738.shtml）。

由此可見，關于異步執(zhí)行機制到底是怎么回事，因為涉及到瀏覽器底層機制，所以不容易徹底了解清楚，就算是大牛阮一峰，也只是通過英文文獻來了解，而且一知半解。我的這篇文章只是試圖盡可能簡單的描述一下JS的異步執(zhí)行機制，坦白說，我現(xiàn)在并不能完全弄懂這個機制，所以也不能完全解釋清這個機制，所以，如果我寫的越嚴謹，就越容易出錯，我只能簡單但是較模糊的描述一下：

JS的運行環(huán)境是一個很復雜的環(huán)境，它里面有非常多的復雜的名詞事物，用簡單又不嚴謹?shù)恼f法來說，運行環(huán)境里至少有下面這些事物：

• 堆 (Heap)：存放變量、對象、函數(shù)等。簡單地說，堆跟咱們這個異步機制主題相關度不大，當然實際上肯定有關聯(lián)。
• 事件隊列 (Event Queue)：可能跟所謂“任務隊列” (Task Queue) 指代同一個事物，它是一個列表，這個列表就是即將被執(zhí)行的任務的列表，它負責給任務排序。事件隊列不止一個，是有多個，比如輸入事件有一個自己的隊列，定時器有一個自己的隊列，所有回調函數(shù)也有一個自己的隊列，等等，然后這些隊列又有優(yōu)先級，某個隊列的優(yōu)先級注定高，比如輸入事件，因為從用戶感受來說，用戶的輸入如果優(yōu)先級不高，用戶會覺得瀏覽器響應慢，會覺得“卡”，甚至可能會把鍵盤或者電腦砸了，后果很嚴重。。。所以必須是第一優(yōu)先級的，然后另有一些隊列優(yōu)先級低，比如回調函數(shù)隊列。最終，這些隊列會形成一個總隊列，而且，這個總隊列隨時會變化，再而且，也是因為優(yōu)先級的關系，經常會有插隊的事情發(fā)生。
  可以這樣理解一下：
  +++++++~~~~~~~~~~~=======########
  以上代表總隊列，分為若干個子隊列，每一個子隊列如果有新任務，也只會加到自己的隊列的末尾，而不會加到總隊列的末尾。有一個執(zhí)行器會挨個執(zhí)行總隊列里的任務。
• 棧 (stack)：它負責根據(jù)事件隊列來執(zhí)行任務，就是說，進來一個任務，然后執(zhí)行，然后扔出去。棧相當于流水線上的干活的操作臂。（此處存疑，棧應該是某種存儲空間，為何成了執(zhí)行者？似乎執(zhí)行者應該是主線程的某個事物。）
• 事件循環(huán) (Event Loop)：事件循環(huán)是事件隊列和棧的關聯(lián)的橋梁，它做的事情是：如果?？樟耍录犃羞€沒空，那么事件循環(huán)就從事件隊列拿出來一個任務，扔給棧。事件循環(huán)相當于一個有眼睛的機械臂，它看到棧空了，事件隊列還有任務，就把任務的第一個抓出來扔給棧，它自己就完事了。
• 主線程：JS是單線程的沒錯，但這只是說JS引擎是單缸驅動的，但是一臺車肯定不是只有發(fā)動機就能在路上跑，發(fā)動機還需要別的部件協(xié)助它才行。在咱們這，別的部件就是指HTTP線程、I/O線程、GUI線程等等，這些線程由瀏覽器提供，跟JS的線程是兩回事了。JS的線程咱們稱為主線程。那么主線程跟上面這些名詞是什么關系呢？尤其是跟棧是什么關系呢？棧肯定是主線程的一個組成部分，任務隊列似乎不是主線程的組成部分。事件循環(huán)跟主線程的關系我不明朗，也可能事件循環(huán)只是一個動詞，而不是名詞。上面幾個名詞解釋的正確性我不確定，請先這么理解吧。

有一個國外的web app，專門用來講解異步事件的門道Loupe，這個更接近真實情況。為什么我不講解這個？因為更復雜了，我們并不打算研究瀏覽器的底層，不是么？

然后說一下任務隊列里的任務。所有任務可以分成兩種，一種是同步任務（synchronous），另一種是異步任務（asynchronous）。同步任務指的是，靠主線程自己就可以執(zhí)行完成的任務；異步任務指的是，主線程執(zhí)行開始之后，需要靠主線程之外的線程才能完成的任務。由主線程決定是否要動用其他線程。以下內容，不再提棧，只說主線程。

現(xiàn)在說重點：

異步任務的執(zhí)行機制是：

當主線程遇到一個異步任務，比如一個ajax請求，當主線程執(zhí)行到xhr.send()的時候，這個send命令是立即執(zhí)行的，并不會像一些人想象的，拖到所有同步任務的最后面。然后主線程向http線程發(fā)送指令，要求http線程向服務器發(fā)送請求。這里強調一下http線程，顯然它不是主線程的一部分，因為它可以并發(fā)，如果你有100個ajax請求，每個都需要1秒鐘，是不是http線程要花100秒呢？并不是，它會并發(fā)100個請求，總共耗時大約1.01秒就完成了。

主線程向以http線程為代表的幾個線程發(fā)送指令之后，主線程就暫時不再管這個ajax任務了，而是去看任務隊列里的下一個任務。

http線程發(fā)送了請求之后接收反饋，收到之后，形成一個新的事件（可以叫做“我收到啦！”事件），然后插入到回調函數(shù)隊列中，因為回調函數(shù)隊列的優(yōu)先級很低，所以會排到總隊列的最后面，其結果就是：主線程把同步任務都完成了，才開始執(zhí)行異步事件的回調。注意，并不是異步任務在全體同步任務結束之后才開始，而是異步任務的回調通常在全體同步任務結束之后才開始！異步任務跟異步任務的回調是兩回事！是兩個任務！一個鮮明的例子就是setTimeout(fn, 1000)，計時是從主線程遇到setTimeout()任務，然后分配給計時器線程，計時器線程開始干活的時候就開始計時了！只不過要1秒之后fn才執(zhí)行！setTimeout()和fn是兩個任務！setTimeout()是立即執(zhí)行，fn才是1秒之后執(zhí)行。但是setTimeout()的執(zhí)行，人眼是感受不到的，因為并沒有什么地方有一個秒表告訴你setTimeout()開始執(zhí)行了；而fn的執(zhí)行，人眼能感受到，所以人們會錯誤的以為fn才是異步任務，其實fn并不是，fn是個回調任務，往往fn是同步任務，比如fn可能是console.log(123)，這怎么會是異步任務。

所以，異步機制是瀏覽器的兩個或以上常駐線程共同完成的，異步請求是JS主線程和其他某個線程共同完成的，JS的執(zhí)行線程發(fā)起異步請求（這時瀏覽器會開一條新的HTTP請求線程來執(zhí)行請求，這時JS自己的任務已完成，繼續(xù)執(zhí)行線程隊列中剩下的其他任務），然后在未來的某一時刻"任務隊列"線程監(jiān)視到之前的發(fā)起的HTTP請求已完成，"任務隊列"就會把完成事件插入到JS執(zhí)行隊列的尾部等待JS處理。

最后專門說說定時觸發(fā)（settimeout和setinterval）。

定時觸發(fā)是由瀏覽器的定時器線程執(zhí)行的定時計數(shù)，然后在定時時間到達之后，定時器線程把定時處理函數(shù)的執(zhí)行請求插入到JS回調隊列的尾端。

setTimeout(function() {
    alert(1);
}, 100);
sometask; // 是個同步任務，假設耗時1000毫秒

這個1到底是100毫秒之后彈出，還是1000毫秒（或更多時間）后彈出呢？又或是1100毫秒之后彈出？

答案是，1000毫秒多一點點之后彈出。

原因：瀏覽器會先執(zhí)行setTimeout，也就是開始計時，然后開始執(zhí)行sometask，執(zhí)行了1000毫秒，然后去回調隊列里看回調任務，alert(1);早就恭候了，因為定時100毫秒之后alert(1)就可以執(zhí)行了。所以，等1000毫秒的任務完成，1就會立即彈出，所以答案是1000毫秒多一點點之后彈出。

所以用這兩個函數(shù)的時候，實際的執(zhí)行時間是大于或等于指定時間的，不保證能準確定時的。

最后強調一下setInterval。比如我希望每100毫秒打印一個1。然后，又有極端情況，就是sometask耗時1000毫秒。你以為sometask結束之后會打出10個1么？并不會，只會打出1個1，因為setInterval第一次讀秒結束之后，回調隊列出現(xiàn)了一個alert(1)，根據(jù)之前的理論，并不會執(zhí)行。又過了100毫秒之后，計時器線程會去觀察回調隊列是不是已經有了alert(1)，如果有，就不再往回調隊列里加alert(1)，目的就是為了避免回調疊加執(zhí)行。

總之，你需要記住，異步任務就是主線程在任務隊列里看到了這個任務，看了一眼之后就然后安排別的線程幫忙，然后主線程就忙別的去了，別的線程幫忙完事之后，再在隊列末尾放一個新任務叫“幫忙完畢”，到此異步任務本身就完事。主任務看到“幫忙完畢”任務之后，就去執(zhí)行回調，回調執(zhí)行完，這個異步任務連同回調就全都完事。然后，如果并沒有回調。。。沒有就沒有唄。