摘要：在異步機制中，任務隊列就是用來維護異步任務回調函數的隊列。四對象對象是工作組提出的一種規范，目的是為異步編程提供統一接口。

Javascript語言的執行環境是"單線程"（single thread）。所謂"單線程"，就是指一次只能完成一件任務。如果有多個任務，就必須排隊，前面一個任務完成，再執行后面一個任務，以此類推。

單線程模式的好處是實現起來比較簡單，執行環境相對單純；
壞處是只要有一個任務耗時很長，后面的任務都必須排隊等著，會拖延整個程序的執行。常見的瀏覽器無響應（假死），往往就是因為某一段Javascript代碼長時間運行（比如死循環），導致整個頁面卡在這個地方，其他任務無法執行。

JS代碼可以修改DOM結構，如果JS是多線程的，當不同JS線程可能同時修改DOM結構，JS設計成單線程可以避免DOM渲染沖突。Webwork支持多線程，但是不能訪問DOM。

由于JavaScript是可操縱DOM的，如果在修改這些元素屬性同時渲染界面（即JS線程和UI線程同時運行），那么渲染線程前后獲得的元素數據就可能不一致了。
因此為了防止渲染出現不可預期的結果，瀏覽器設置GUI渲染線程與JS引擎為互斥的關系，當JS引擎執行時GUI線程會被掛起， GUI更新則會被保存在一個隊列中等到JS引擎線程空閑時立即被執行。
所以如果JS執行的時間過長，這樣就會造成頁面的渲染不連貫，導致頁面渲染加載阻塞。

Javascript語言將任務的執行模式分成兩種：同步（Synchronous）和異步（Asynchronous）
"同步模式"就是上一段的模式，后一個任務等待前一個任務結束，然后再執行，程序的執行順序與任務的排列順序是一致的、同步的；
"異步模式"則完全不同，每一個任務有一個或多個回調函數（callback），前一個任務結束后，不是執行后一個任務，而是執行回調函數，后一個任務則是不等前一個任務結束就執行，所以程序的執行順序與任務的排列順序是不一致的、異步的。
"異步模式"非常重要。在瀏覽器端，耗時很長的操作都應該異步執行，避免瀏覽器失去響應，最好的例子就是Ajax操作。在服務器端，"異步模式"甚至是唯一的模式，因為執行環境是單線程的，如果允許同步執行所有http請求，服務器性能會急劇下降，很快就會失去響應。

相信不少人對Javascript單線程表示懷疑：為何單線程可以實現異步操作呢？其實Javascript確實是單線程的（我們不妨把這個線程稱作主線程），但它實現異步操作的方式確實借助了瀏覽器的其他線程的幫助。那其他線程是怎么幫助Javascript主線程來實現異步的呢？答案就是任務隊列（task queue）和事件循環（event loop）。

一、任務隊列
首先，作為單線程語言，在Javascript中定義的任務都會在主線程中執行。但是并不是每個任務都會立刻執行，而這種不立刻執行的任務我們稱作異步任務。相反，那些立刻執行的任務我們把它們稱作同步任務。而這些異步任務都會交給瀏覽器的其他線程去執行，但是主線程需要了解這些異步任務執行的狀態，才方便進行下一步操作。

打個比方，主線程準備做飯，所以下達一個異步任務去買菜，異步任務買完菜之后得告訴主線程：“我買完菜啦”，這個時候主線程才好開始做飯。

而我們知道因為Javascript是單線程，所以上述的“下一步操作”沒法直接定義在主函數里（不然就被當做同步任務直接執行了），那這些應該定義在哪里呢？答案就是異步任務的回調函數中。在Javascript異步機制中，任務隊列就是用來維護異步任務回調函數的隊列。這樣一個隊列用來存放這些回調函數，它們會等到主線程執行完所有的同步函數之后按照先進先出的方式挨個執行。那么執行完任務隊列之后呢？Javascript主線程就執行完畢了嗎？當然不是，不然網頁加載完畢之后，誰來處理后續與用戶的交互事件（比如點擊事件）呢？
二、事件循環
Javascript的異步機制:
執行同步任務 -> 檢查任務隊列中是否有任務 -> [有如果則執行] -> 檢查任務隊列中是否有任務 -> [有如果則執行] -> ......
可見主線程在執行完同步任務之后，會無限循環地去檢查任務隊列中是否有新的“任務”，如果有則執行。而這些任務包括我們在異步任務中定義的回調函數，也包括用戶交互事件的回調函數。通過事件循環，Javascript不僅很好的處理了異步任務，也很好的完成了與用戶交互事件的處理。因為在完成異步任務的回調函數之后，任務隊列中的任務都是由事件所產生的，因此我們也把上述的循環過程叫做事件循環。

總而言之，Javascript單線程的背后有瀏覽器的其他線程為其完成異步服務，這些異步任務為了和主線程通信，通過將回調函數推入到任務隊列等待執行。主線程所做的就是執行完同步任務后，通過事件循環，不斷地檢查并執行任務隊列中回調函數。

一、回調函數
這是異步編程最基本的方法。

假定有兩個函數f1和f2，后者等待前者的執行結果。如果f1是一個很耗時的任務，可以考慮改寫f1，把f2寫成f1的回調函數。

function f1(callback){

　　　　setTimeout(function () {

　　　　　　// f1的任務代碼

　　　　　　callback();

　　　　}, 1000);

　　}
//執行代碼：

　　f1(f2);

采用這種方式，我們把同步操作變成了異步操作，f1不會堵塞程序運行，相當于先執行程序的主要邏輯，將耗時的操作推遲執行。

回調函數的優點是簡單、容易理解和部署，缺點是不利于代碼的閱讀和維護，各個部分之間高度耦合（Coupling），流程會很混亂，而且每個任務只能指定一個回調函數。

二、事件監聽
另一種思路是采用事件驅動模式。任務的執行不取決于代碼的順序，而取決于某個事件是否發生。

還是以f1和f2為例。首先，為f1綁定一個事件（這里采用的jQuery的寫法）。

function f1(){

　　　　setTimeout(function () {

　　　　　　// f1的任務代碼

f1.trigger("done");

　　　　}, 1000);

　　}


f1.on("done", f2);

這種方法的優點是比較容易理解，可以綁定多個事件，每個事件可以指定多個回調函數，而且可以"去耦合"（Decoupling），有利于實現模塊化。缺點是整個程序都要變成事件驅動型，運行流程會變得很不清晰。
三、發布/訂閱
上一節的"事件"，完全可以理解成"信號"。
我們假定，存在一個"信號中心"，某個任務執行完成，就向信號中心"發布"（publish）一個信號，其他任務可以向信號中心"訂閱"（subscribe）這個信號，從而知道什么時候自己可以開始執行。這就叫做"發布/訂閱模式"（publish-subscribe pattern），又稱"觀察者模式"（observer pattern）。
這個模式有多種實現，下面采用的是Ben Alman的Tiny Pub/Sub，這是jQuery的一個插件。
首先，f2向"信號中心"jQuery訂閱"done"信號。

jQuery.subscribe("done", f2);

function f1(){

　　　　setTimeout(function () {

　　　　　　// f1的任務代碼

jQuery.publish("done");

　　　　}, 1000);

　　}

jQuery.publish("done")的意思是，f1執行完成后，向"信號中心"jQuery發布"done"信號，從而引發f2的執行。
此外，f2完成執行后，也可以取消訂閱（unsubscribe）?！　?/p>

jQuery.unsubscribe("done", f2);

這種方法的性質與"事件監聽"類似，但是明顯優于后者。因為我們可以通過查看"消息中心"，了解存在多少信號、每個信號有多少訂閱者，從而監控程序的運行。
四、Promises對象
Promises對象是CommonJS工作組提出的一種規范，目的是為異步編程提供統一接口。
簡單說，它的思想是，每一個異步任務返回一個Promise對象，該對象有一個then方法，允許指定回調函數。比如，f1的回調函數f2,可以寫成：

f1().then(f2);

f1要進行如下改寫（這里使用的是jQuery的實現）：

function f1(){
　　　　var dfd = $.Deferred();
　　　　setTimeout(function () {
　　　　　　// f1的任務代碼
　　　　　　dfd.resolve();
　　　　}, 500);
       return dfd.promise;
　　}

這樣寫的優點在于，回調函數變成了鏈式寫法，程序的流程可以看得很清楚，而且有一整套的配套方法，可以實現許多強大的功能。
比如，指定多個回調函數：

　f1().then(f2).then(f3);

再比如，指定發生錯誤時的回調函數：

f1().then(f2).fail(f3);

而且，它還有一個前面三種方法都沒有的好處：如果一個任務已經完成，再添加回調函數，該回調函數會立即執行。所以，你不用擔心是否錯過了某個事件或信號。這種方法的缺點就是編寫和理解，都相對比較難。

瀏覽器是多進程的
瀏覽器之所以能夠運行，是因為系統給它的進程分配了資源（cpu、內存）
簡單點理解，每打開一個Tab頁，就相當于創建了一個獨立的瀏覽器進程（渲染進程）。

瀏覽器的渲染進程是多線程的，頁面的渲染，JS的執行，事件的循環，都在這個進程內進行。
渲染進程包含了哪些線程（列舉一些主要常駐線程）：
1.GUI渲染線程
負責渲染瀏覽器界面，解析HTML，CSS，構建DOM樹和RenderObject樹，布局和繪制等。
當界面需要重繪（Repaint）或由于某種操作引發回流(reflow)時，該線程就會執行
注意，GUI渲染線程與JS引擎線程是互斥的，當JS引擎執行時GUI線程會被掛起（相當于被凍結了），GUI更新會被保存在一個隊列中等到JS引擎空閑時立即被執行。
2.JS引擎線程
也稱為JS內核，負責處理Javascript腳本程序。（例如V8引擎）
JS引擎線程負責解析Javascript腳本，運行代碼。
JS引擎一直等待著任務隊列中任務的到來，然后加以處理，瀏覽器無論什么時候都只有一個JS線程在運行JS程序
同樣注意，GUI渲染線程與JS引擎線程是互斥的，所以如果JS執行的時間過長，這樣就會造成頁面的渲染不連貫，導致頁面渲染加載阻塞。
3.事件觸發線程
歸屬于瀏覽器而不是JS引擎，用來控制事件循環（可以理解，JS引擎自己都忙不過來，需要瀏覽器另開線程協助）
當JS引擎執行代碼塊如setTimeOut時（也可來自瀏覽器內核的其他線程,如鼠標點擊、AJAX異步請求等），會將對應任務添加到事件線程中
當對應的事件符合觸發條件被觸發時，該線程會把事件添加到待處理隊列的隊尾，等待JS引擎的處理
注意，由于JS的單線程關系，所以這些待處理隊列中的事件都得排隊等待JS引擎處理（當JS引擎空閑時才會去執行）
4.定時觸發器線程
傳說中的setInternal與setTimeout所在線程
瀏覽器定時計數器并不是由JavaScript引擎計數的,（因為JavaScript引擎是單線程的, 如果處于阻塞線程狀態就會影響記計時的準確）
因此通過多帶帶線程來計時并觸發定時（計時完畢后，添加到事件隊列中，等待JS引擎空閑后執行）
注意，W3C在HTML標準中規定，規定要求setTimeout中低于4ms的時間間隔算為4ms。
5.異步http請求線程
在XMLHttpRequest在連接后是通過瀏覽器新開一個線程請求
將檢測到狀態變更時，如果設置有回調函數，異步線程就產生狀態變更事件，將這個回調再放入事件隊列中。再由JavaScript引擎執行。

參考資料
1.JS異步編程異步編程的方法和原理