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

JS的執行環境是一個很複雜的環境，它裡面有非常多的複雜的名詞事物，用簡單又不嚴謹的說法來說，執行環境裡至少有下面這些事物：

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

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

然後說一下任務佇列裡的任務。所有任務可以分成兩種，一種是同步任務（synchronous），另一種是非同步任務（asynchronous）。同步任務指的是，靠主執行緒自己就可以執行完成的任務；非同步任務指的是，主執行緒執行開始之後，需要靠主執行緒之外的執行緒才能完成的任務。由主執行緒決定是否要動用其他執行緒。以下內容，不再提棧，只說主執行緒。

現在說重點：

非同步任務的執行機制是：

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

主執行緒向以http執行緒為代表的幾個執行緒傳送指令之後，主執行緒就暫時不再管這個ajax任務了，而是去看任務佇列裡的下一個任務。

http執行緒傳送了請求之後接收反饋，收到之後，形成一個新的事件（可以叫做“我收到啦！”事件），然後插入到回撥函式佇列中，因為回撥函式佇列的優先順序很低，所以會排到總佇列的最後面，其結果就是：主執行緒把同步任務都完成了，才開始執行非同步事件的回撥。注意，並不是非同步任務在全體同步任務結束之後才開始，而是非同步任務的回撥通常在全體同步任務結束之後才開始！非同步任務跟非同步任務的回撥是兩回事！是兩個任務！一個鮮明的例子就是setTimeout(fn, 1000)，計時是從主執行緒遇到setTimeout()任務，然後分配給計時器執行緒，計時器執行緒開始幹活的時候就開始計時了！只不過要1秒之後fn才執行！setTimeout()和fn是兩個任務！setTimeout()是立即執行，fn才是1秒之後執行。但是setTimeout()的執行，人眼是感受不到的，因為並沒有什麼地方有一個秒錶告訴你setTimeout()開始執行了；而fn的執行，人眼能感受到，所以人們會錯誤的以為fn才是非同步任務，其實fn並不是，fn是個回撥任務，往往fn是同步任務，比如fn可能是console.log(123)，這怎麼會是非同步任務。

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

最後專門說說定時觸發（settimeout和setinterval）。

定時觸發是由瀏覽器的定時器執行緒執行的定時計數，然後在定時時間到達之後，定時器執行緒把定時處理函式的執行請求插入到JS回撥佇列的尾端。

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

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

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

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

所以用這兩個函式的時候，實際的執行時間是大於或等於指定時間的，不保證能準確定時的。

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

總之，你需要記住，非同步任務就是主執行緒在任務佇列裡看到了這個任務，看了一眼之後就然後安排別的執行緒幫忙，然後主執行緒就忙別的去了，別的執行緒幫忙完事之後，再在佇列末尾放一個新任務叫“幫忙完畢”，到此非同步任務本身就完事。主任務看到“幫忙完畢”任務之後，就去執行回撥，回撥執行完，這個非同步任務連同回撥就全都完事。然後，如果並沒有回撥。。。沒有就沒有唄。