感謝社區中各位的大力支持，譯者再次奉上一點點福利：阿里云產品券，享受所有官網優惠，并抽取幸運大獎：點擊這里領取
在像JavaScript這樣的語言中最重要但經常被誤解的編程技術之一，就是如何表達和操作跨越一段時間的程序行為。
這不僅僅是關于從for循環開始到for循環結束之間發生的事情，當然它確實要花 一些時間（幾微秒到幾毫秒）才能完成。它是關于你的程序 現在 運行的部分，和你的程序 稍后 運行的另一部分之間發生的事情——現在 和 稍后 之間有一個間隙，在這個間隙中你的程序沒有活躍地執行。
幾乎所有被編寫過的（特別是用JS）大型程序都不得不用這樣或那樣的方法來管理這個間隙，不管是等待用戶輸入，從數據庫或文件系統請求數據，通過網絡發送數據并等待應答，還是在規定的時間間隔重復某些任務（比如動畫）。在所有這些各種方法中，你的程序都不得不跨越時間間隙管理狀態。就像在倫敦眾所周知的一句話（地鐵門與月臺間的縫隙）：“小心間隙。”
實際上，你程序中 現在 與 稍后 的部分之間的關系，就是異步編程的核心。
可以確定的是，異步編程在JS的最開始就出現了。但是大多數開發者從沒認真地考慮過它到底是如何，為什么出現在他們的程序中的，也沒有探索過 其他 處理異步的方式。足夠好 的方法總是老實巴交的回調函數。今天還有許多人堅持認為回調就綽綽有余了。
但是JS在使用范圍和復雜性上不停地生長，作為運行在瀏覽器，服務器和每種可能的設備上的頭等編程語言，為了適應它不斷擴大的要求，我們在管理異步上感受到的痛苦日趨嚴重，人們迫切地需要一種更強大更合理的處理方法。
雖然眼前這一切看起來很抽象，但我保證，隨著我們通讀這本書你會更完整且堅實地解決它。在接下來的幾章中我們將會探索各種異步JavaScript編程的新興技術。
但在接觸它們之前，我們將不得不更深刻地理解異步是什么，以及它在JS中如何運行。
塊兒（Chunks）中的程序
你可能將你的JS程序寫在一個 .js 文件中，但幾乎可以確定你的程序是由幾個代碼塊兒構成的，僅有其中的一個將會在 現在 執行，而其他的將會在 稍后 執行。最常見的 代碼塊兒 單位是function。
大多數剛接觸JS的開發者都可能會有的問題是，稍后 并不嚴格且立即地在 現在 之后發生。換句話說，根據定義，現在 不能完成的任務將會異步地完成，而且我們因此不會有你可能在直覺上期望或想要的阻塞行為。
考慮這段代碼：
// ajax(..)是某個包中任意的Ajax函數
var data = ajax( "http://some.url.1" );
console.log( data );
// 噢！`data`一般不會有Ajax的結果
你可能意識到Ajax請求不會同步地完成，這意味著ajax(..)函數還沒有任何返回的值可以賦值給變量data。如果ajax(..)在應答返回之前 能夠 阻塞，那么data = ..賦值將會正常工作。
但那不是我們使用Ajax的方式。我們 現在 制造一個異步的Ajax請求，直到 稍后 我們才會得到結果。
從 現在 “等到” 稍后 最簡單的（但絕對不是唯一的，或最好的）方法，通常稱為回調函數：
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", function myCallbackFunction(data){
console.log( data ); // Yay, 我得到了一些`data`!
} );
警告： 你可能聽說過發起同步的Ajax請求是可能的。雖然在技術上是這樣的，但你永遠，永遠不應該在任何情況下這樣做，因為它將鎖定瀏覽器的UI（按鈕，菜單，滾動條，等等）而且阻止用戶與任何東西互動。這是一個非常差勁的主意，你應當永遠回避它。
在你提出抗議之前，不，你渴望避免混亂的回調不是使用阻塞的，同步的Ajax的正當理由。
舉個例子，考慮下面的代碼：
function now() {
return 21;
}
function later() {
answer = answer * 2;
console.log( "Meaning of life:", answer );
}
var answer = now();
setTimeout( later, 1000 ); // Meaning of life: 42
這個程序中有兩個代碼塊兒：現在 將會運行的東西，和 稍后 將會運行的東西。這兩個代碼塊分別是什么應當十分明顯，但還是讓我們以最明確的方式指出來：
現在：
function now() {
return 21;
}
function later() { .. }
var answer = now();
setTimeout( later, 1000 );
稍后：
answer = answer * 2;
console.log( "Meaning of life:", answer );
你的程序一執行，現在 代碼塊兒就會立即運行。但setTimeout(..)還設置了一個 稍后 會發生的事件（一個超時事件），所以later()函數的內容將會在一段時間后（從現在開始1000毫秒）被執行。
每當你將一部分代碼包進function并且規定它應當為了響應某些事件而執行（定時器，鼠標點擊，Ajax應答等等），你就創建了一個 稍后 代碼塊兒，也因此在你的程序中引入了異步。
異步控制臺
關于console.*方法如何工作，沒有相應的語言規范或一組需求——它們不是JavaScript官方的一部分，而是由 宿主環境 添加到JS上的（見本叢書的 類型與文法）。
所以，不同的瀏覽器和JS環境各自為戰，這有時會導致令人困惑的行為。
特別地，有些瀏覽器和某些條件下，console.log(..)實際上不會立即輸出它得到的東西。這個現象的主要原因可能是因為I/O處理很慢，而且是許多程序的阻塞部分（不僅是JS）。所以，對一個瀏覽器來說，可能的性能更好的處理方式是（從網頁/UI的角度看），在后臺異步地處理consoleI/O，而你也許根本不知道它發生了。
雖然不是很常見，但是一種可能被觀察到（不是從代碼本身，而是從外部）的場景是：
var a = {
index: 1
};
// 稍后
console.log( a ); // ??
// 再稍后
a.index++;
我們一般希望看到的是，就在console.log(..)語句被執行的那一刻，對象a被取得一個快照，打印出如{ index: 1 }的內容，如此在下一個語句a.index++執行時，它修改不同于a的輸出，或者嚴格的在a的輸出之后的某些東西。
大多數時候，上面的代碼將會在你的開發者工具控制臺中產生一個你期望的對象表現形式。但是同樣的代碼也可能運行在這樣的情況下：瀏覽器告訴后臺它需要推遲控制臺I/O，這時，在對象在控制臺中被表示的那個時間點，a.index++已經執行了，所以它將顯示{ index: 2 }。
到底在什么條件下consoleI/O將被推遲是不確定的，甚至它能不能被觀察到都是不確定的。只能當你在調試過程中遇到問題時——對象在console.log(..)語句之后被修改，但你卻意外地看到了修改后的內容——意識到I/O的這種可能的異步性。
注意： 如果你遇到了這種罕見的情況，最好的選擇是使用JS調試器的斷點，而不是依賴console的輸出。第二好的選擇是通過將目標對象序列化為一個string強制取得一個它的快照，比如用JSON.stringify(..)。
事件輪詢（Event Loop）
讓我們來做一個（也許是令人震驚的）聲明：盡管明確地允許異步JS代碼（就像我們剛看到的超時），但是實際上，直到最近（ES6）為止，JavaScript本身從來沒有任何內建的異步概念。
什么！？ 這聽起來簡直是瘋了，對吧？事實上，它是真的。JS引擎本身除了在某個在被要求的時刻執行你程序的一個單獨的代碼塊外，沒有做過任何其他的事情。
“被'誰'要求”？這才是重要的部分！
JS引擎沒有運行在隔離的區域。它運行在一個 宿主環境 中，對大多數開發者來說這個宿主環境就是瀏覽器。在過去的幾年中（但不特指這幾年），JS超越了瀏覽器的界限進入到了其他環境中，比如服務器，通過Node.js這樣的東西。其實，今天JavaScript已經被嵌入到所有種類的設備中，從機器人到電燈泡兒。
所有這些環境的一個共通的“線程”（一個“不那么微妙”的異步玩笑，不管怎樣）是，他們都有一種機制：在每次調用JS引擎時，可以 隨著時間的推移 執行你的程序的多個代碼塊兒，這稱為“事件輪詢（Event Loop）”。
換句話說，JS引擎對 時間 沒有天生的感覺，反而是一個任意JS代碼段的按需執行環境。是它周圍的環境在不停地安排“事件”（JS代碼的執行）。
那么，舉例來說，當你的JS程序發起一個從服務器取得數據的Ajax請求時，你在一個函數（通常稱為回調）中建立好“應答”代碼，然后JS引擎就會告訴宿主環境，“嘿，我就要暫時停止執行了，但不管你什么時候完成了這個網絡請求，而且你還得到一些數據的話，請 回來調 這個函數。”
然后瀏覽器就會為網絡的應答設置一個監聽器，當它有東西要交給你的時候，它會通過將回調函數插入 事件輪詢 來安排它的執行。
那么什么是 事件輪詢？
讓我們先通過一些假想代碼來對它形成一個概念：
// `eventLoop`是一個像隊列一樣的數組（先進先出）
var eventLoop = [ ];
var event;
// “永遠”執行
while (true) {
// 執行一個"tick"
if (eventLoop.length > 0) {
// 在隊列中取得下一個事件
event = eventLoop.shift();
// 現在執行下一個事件
try {
event();
}
catch (err) {
reportError(err);
}
}
}
當然，這只是一個用來展示概念的大幅簡化的假想代碼。但是對于幫助我們建立更好的理解來說應該夠了。
如你所見，有一個通過while循環來表現的持續不斷的循環，這個循環的每一次迭代稱為一個“tick”。在每一個“tick”中，如果隊列中有一個事件在等待，它就會被取出執行。這些事件就是你的函數回調。
很重要并需要注意的是，setTimeout(..)不會將你的回調放在事件輪詢隊列上。它設置一個定時器；當這個定時器超時的時候，環境才會把你的回調放進事件輪詢，這樣在某個未來的tick中它將會被取出執行。
如果在那時事件輪詢隊列中已經有了20個事件會怎么樣？你的回調要等待。它會排到隊列最后——沒有一般的方法可以插隊和跳到隊列的最前方。這就解釋了為什么setTimeout(..)計時器可能不會完美地按照預計時間觸發。你得到一個保證（粗略地說）：你的回調不會再你指定的時間間隔之前被觸發，但是可能會在這個時間間隔之后被觸發，具體要看事件隊列的狀態。
換句話說，你的程序通常被打斷成許多小的代碼塊兒，它們一個接一個地在事件輪詢隊列中執行。而且從技術上說，其他與你的程序沒有直接關系的事件也可以穿插在隊列中。
注意： 我們提到了“直到最近”，暗示著ES6改變了事件輪詢隊列在何處被管理的性質。這主要是一個正式的技術規范，ES6現在明確地指出了事件輪詢應當如何工作，這意味著它技術上屬于JS引擎應當關心的范疇內，而不僅僅是 宿主環境。這么做的一個主要原因是為了引入ES6的Promises（我們將在第三章討論），因為人們需要有能力對事件輪詢隊列的排隊操作進行直接，細粒度的控制（參見“協作”一節中關于setTimeout(..0)的討論）。
并行線程
將“異步”與“并行”兩個詞經常被混為一談，但它們實際上是十分不同的。記住，異步是關于 現在 與 稍后 之間的間隙。但并行是關于可以同時發生的事情。
關于并行計算最常見的工具就是進程與線程。進程和線程獨立地，可能同時地執行：在不同的處理器上，甚至在不同的計算機上，而多個線程可以共享一個進程的內存資源。
相比之下，一個事件輪詢將它的工作打碎成一系列任務并串行地執行它們，不允許并行訪問和更改共享的內存。并行與“串行”可能以在不同線程上的事件輪詢協作的形式共存。
并行線程執行的穿插，與異步事件的穿插發生在完全不同的粒度等級上：
比如：
function later() {
answer = answer * 2;
console.log( "Meaning of life:", answer );
}
雖然later()的整個內容將被當做一個事件輪詢隊列的實體，但當考慮到將要執行這段代碼的線程時，實際上也許會有許多不同的底層操作。比如，answer = answer * 2首先需要讀取當前answer的值，再把2放在某個地方，然后進行乘法計算，最后把結果存回到answer。
在一個單線程環境中，線程隊列中的內容都是底層操作真的無關緊要，因為沒有什么可以打斷線程。但如果你有一個并行系統，在同一個程序中有兩個不同的線程，你很可能會得到無法預測的行為：
考慮這段代碼：
var a = 20;
function foo() {
a = a + 1;
}
function bar() {
a = a * 2;
}
// ajax(..) 是一個給定的庫中的隨意Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
在JavaScript的單線程行為下，如果foo()在bar()之前執行，結果a是42，但如果bar()在foo()之前執行，結果a將是41。
如果JS事件共享相同的并列執行數據，問題將會變得微妙得多。考慮這兩個假想代碼段，它們分別描述了運行foo()和bar()中代碼的線程將要執行的任務，并考慮如果它們在完全相同的時刻運行會發生什么：
線程1（X和Y是臨時的內存位置）：
foo():
a. 將`a`的值讀取到`X`
b. 將`1`存入`Y`
c. 把`X`和`Y`相加，將結果存入`X`
d. 將`X`的值存入`a`
線程2（X和Y是臨時的內存位置）：
bar():
a. 將`a`的值讀取到`X`
b. 將`2`存入`Y`
c. 把`X`和`Y`相乘，將結果存入`X`
d. 將`X`的值存入`a`
現在，讓我們假定這兩個線程在并行執行。你可能發現了問題，對吧？它們在臨時的步驟中使用共享的內存位置X和Y。
如果步驟像這樣發生，a的最終結果什么？
1a (將`a`的值讀取到`X` ==> `20`)
2a (將`a`的值讀取到`X` ==> `20`)
1b (將`1`存入`Y` ==> `1`)
2b (將`2`存入`Y` ==> `2`)
1c (把`X`和`Y`相加，將結果存入`X` ==> `22`)
1d (將`X`的值存入`a` ==> `22`)
2c (把`X`和`Y`相乘，將結果存入`X` ==> `44`)
2d (將`X`的值存入`a` ==> `44`)
a中的結果將是44。那么這種順序呢？
1a (將`a`的值讀取到`X` ==> `20`)
2a (將`a`的值讀取到`X` ==> `20`)
2b (將`2`存入`Y` ==> `2`)
1b (將`1`存入`Y` ==> `1`)
2c (把`X`和`Y`相乘，將結果存入`X` ==> `20`)
1c (把`X`和`Y`相加，將結果存入`X` ==> `21`)
1d (將`X`的值存入`a` ==> `21`)
2d (將`X`的值存入`a` ==> `21`)
a中的結果將是21。
所以，關于線程的編程十分刁鉆，因為如果你不采取特殊的步驟來防止這樣的干擾/穿插，你會得到令人非常詫異的，不確定的行為。這通常讓人頭疼。
JavaScript從不跨線程共享數據，這意味著不必關心這一層的不確定性。但這并不意味著JS總是確定性的。記得前面foo()和bar()的相對順序產生兩個不同的結果嗎（41或42）？
注意： 可能還不明顯，但不是所有的不確定性都是壞的。有時候它無關緊要，有時候它是故意的。我們會在本章和后續幾章中看到更多的例子。
運行至完成
因為JavaScript是單線程的，foo()（和bar()）中的代碼是原子性的，這意味著一旦foo()開始運行，它的全部代碼都會在bar()中的任何代碼可以運行之前執行完成，反之亦然。這稱為“運行至完成”行為。
事實上，運行至完成的語義會在foo()與bar()中有更多的代碼時更明顯，比如：
var a = 1;
var b = 2;
function foo() {
a++;
b = b * a;
a = b + 3;
}
function bar() {
b--;
a = 8 + b;
b = a * 2;
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
因為foo()不能被bar()打斷，而且bar()不能被foo()打斷，所以這個程序根據哪一個先執行只有兩種可能的結果——如果線程存在，foo()和bar()中的每一個語句都可能被穿插，可能的結果數量將會極大地增長!
代碼塊兒1是同步的（現在 發生），但代碼塊兒2和3是異步的（稍后 發生），這意味著它們的執行將會被時間的間隙分開。
代碼塊兒1:
var a = 1;
var b = 2;
代碼塊兒2 (foo()):
a++;
b = b * a;
a = b + 3;
代碼塊兒3 (bar()):
b--;
a = 8 + b;
b = a * 2;
代碼塊兒2和3哪一個都有可能先執行，所以這個程序有兩個可能的結果，正如這里展示的：
結果1:
var a = 1;
var b = 2;
// foo()
a++;
b = b * a;
a = b + 3;
// bar()
b--;
a = 8 + b;
b = a * 2;
a; // 11
b; // 22
結果2:
var a = 1;
var b = 2;
// bar()
b--;
a = 8 + b;
b = a * 2;
// foo()
a++;
b = b * a;
a = b + 3;
a; // 183
b; // 180
同一段代碼有兩種結果仍然意味著不確定性！但是這是在函數（事件）順序的水平上，而不是在使用線程時語句順序的水平上（或者說，實際上是表達式操作的順序上）。換句話說，他比線程更具有 確定性。
當套用到JavaScript行為時，這種函數順序的不確定性通常稱為“競合狀態”，因為foo()和bar()在互相競爭看誰會先運行。明確地說，它是一個“競合狀態”因為你不能可靠地預測a與b將如何產生。
注意： 如果在JS中不知怎的有一個函數沒有運行至完成的行為，我們會有更多可能的結果，對吧？ES6中引入一個這樣的東西（見第四章“生成器”），但現在不要擔心，我們會回頭討論它。
并發
讓我們想象一個網站，它顯示一個隨著用戶向下滾動而逐步加載的狀態更新列表（就像社交網絡的新消息）。要使這樣的特性正確工作，（至少）需要兩個分離的“進程” 同時 執行（在同一個時間跨度內，但沒必要是同一個時間點）。
注意： 我們在這里使用帶引號的“進程”，因為它們不是計算機科學意義上的真正的操作系統級別的進程。它們是虛擬進程，或者說任務，表示一組邏輯上關聯，串行順序的操作。我們將簡單地使用“進程”而非“任務”，因為在術語層面它與我們討論的概念的定義相匹配。
第一個“進程”將響應當用戶向下滾動頁面時觸發的onscroll事件（發起取得新內容的Ajax請求）。第二個“進程”將接收返回的Ajax應答（將內容繪制在頁面上）。
顯然，如果用戶向下滾動的足夠快，你也許會看到在第一個應答返回并處理期間，有兩個或更多的onscroll事件被觸發，因此你將使onscroll事件和Ajax應答事件迅速觸發，互相穿插在一起。
并發是當兩個或多個“進程”在同一時間段內同時執行，無論構成它們的各個操作是否 并行地（在同一時刻不同的處理器或內核）發生。你可以認為并發是“進程”級別的（或任務級別）的并行機制，而不是操作級別的并行機制（分割進程的線程）。
注意： 并發還引入了這些“進程”間彼此互動的概念。我們稍后會討論它。
在一個給定的時間跨度內（用戶可以滾動的那幾秒），讓我們將每個獨立的“進程”作為一系列事件/操作描繪出來：
“線程”1 (onscroll事件):
onscroll, request 1
onscroll, request 2
onscroll, request 3
onscroll, request 4
onscroll, request 5
onscroll, request 6
onscroll, request 7
“線程”2 (Ajax應答事件):
response 1
response 2
response 3
response 4
response 5
response 6
response 7
一個onscroll事件與一個Ajax應答事件很有可能在同一個 時刻 都準備好被處理了。比如我們在一個時間線上描繪一下這些事件的話：
onscroll, request 1
onscroll, request 2 response 1
onscroll, request 3 response 2
response 3
onscroll, request 4
onscroll, request 5
onscroll, request 6 response 4
onscroll, request 7
response 6
response 5
response 7
但是，回到本章前面的事件輪詢概念，JS一次只能處理一個事件，所以不是onscroll, request 2首先發生就是response 1首先發生，但是他們不可能完全在同一時刻發生。就像學校食堂的孩子們一樣，不管他們在門口擠成什么樣，他們最后都不得不排成一個隊來打飯！
讓我們來描繪一下所有這些事件在事件輪詢隊列上穿插的情況：
事件輪詢隊列：
onscroll, request 1 <--- 進程1開始
onscroll, request 2
response 1 <--- 進程2開始
onscroll, request 3
response 2
response 3
onscroll, request 4
onscroll, request 5
onscroll, request 6
response 4
onscroll, request 7 <--- 進程1結束
response 6
response 5
response 7 <--- 進程2結束
“進程1”和“進程2”并發地運行（任務級別的并行），但是它們的個別事件在事件輪詢隊列上順序地運行。
順便說一句，注意到response 6和response 5沒有按照預想的順序應答嗎？
單線程事件輪詢是并發的一種表達（當然還有其他的表達，我們稍后討論）。
非互動
在同一個程序中兩個或更多的“進程”在穿插它們的步驟/事件時，如果它們的任務之間沒有聯系，那么他們就沒必要互動。如果它們不互動，不確定性就是完全可以接受的。
舉個例子：
var res = {};
function foo(results) {
res.foo = results;
}
function bar(results) {
res.bar = results;
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
foo()和bar()是兩個并發的“進程”，而且它們被觸發的順序是不確定的。但對我們的程序的結構來講它們的觸發順序無關緊要，因為它們的行為相互獨立所以不需要互動。
這不是一個“競合狀態”Bug，因為這段代碼總能夠正確工作，與順序無關。
互動
更常見的是，通過作用域和/或DOM，并發的“進程”將有必要間接地互動。當這樣的互動將要發生時，你需要協調這些互動行為來防止前面講述的“競合狀態”。
這里是兩個由于隱含的順序而互動的并發“進程”的例子，它 有時會出錯：
var res = [];
function response(data) {
res.push( data );
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", response );
ajax( "http://some.url.2", response );
并發的“進程”是那兩個將要處理Ajax應答的response()調用。它們誰都有可能先發生。
假定我們期望的行為是res[0]擁有"http://some.url.1"調用的結果，而res[1]擁有"http://some.url.2"調用的結果。有時候結果確實是這樣，而有時候則相反，要看哪一個調用首先完成。很有可能，這種不確定性是一個“競合狀態”Bug。
注意： 在這些情況下要極其警惕你可能做出的主觀臆測。比如這樣的情況就沒什么不尋常：一個開發者觀察到"http://some.url.2"的應答“總是”比"http://some.url.1"要慢得多，也許有賴于它們所做的任務（比如，一個執行數據庫任務而另一個只是取得靜態文件），所以觀察到的順序看起來總是所期望的。就算兩個請求都發到同一個服務器，而且它故意以確定的順序應答，也不能 真正 保證應答回到瀏覽器的順序。
所以，為了解決這樣的競合狀態，你可以協調互動的順序：
var res = [];
function response(data) {
if (data.url == "http://some.url.1") {
res[0] = data;
}
else if (data.url == "http://some.url.2") {
res[1] = data;
}
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", response );
ajax( "http://some.url.2", response );
無論哪個Ajax應答首先返回，我們都考察它的data.url（當然，假設這樣的數據會從服務器返回）來找到應答數據應當在res數組中占有的位置。res[0]將總是持有"http://some.url.1"的結果，而res[1]將總是持有"http://some.url.2"的結果。通過簡單的協調，我們消除了“競合狀態”的不確定性。
這個場景的同樣道理可以適用于這樣的情況：多個并發的函數調用通過共享的DOM互動，比如一個在更新<div>的內容而另一個在更新<div>的樣式或屬性（比如一旦DOM元素擁有內容就使它變得可見）。你可能不想在DOM元素擁有內容之前顯示它，所以協調工作就必須保證正確順序的互動。
沒有協調的互動，有些并發的場景 總是出錯（不僅僅是 有時）。考慮下面的代碼：
var a, b;
function foo(x) {
a = x * 2;
baz();
}
function bar(y) {
b = y * 2;
baz();
}
function baz() {
console.log(a + b);
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
在這個例子中，不管foo()和bar()誰先觸發，總是會使baz()運行的太早了（a和b之一還是空的時候），但是第二個baz()調用將可以工作，因為a和b將都是可用的。
有許多不同的方法可以解決這個狀態。這是簡單的一種：
var a, b;
function foo(x) {
a = x * 2;
if (a && b) {
baz();
}
}
function bar(y) {
b = y * 2;
if (a && b) {
baz();
}
}
function baz() {
console.log( a + b );
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
baz()調用周圍的if (a && b)條件通常稱為“大門”，因為我們不能確定a和b到來的順序，但在打開大門（調用baz()）之前我們等待它們全部到達。
另一種你可能會遇到的并發互動狀態有時稱為“競爭”，單更準確地說應該叫“門閂”。它的行為特點是“先到者勝”。在這里不確定性是可以接受的，因為你明確指出“競爭”的終點線上只有一個勝利者。
考慮這段有問題的代碼：
var a;
function foo(x) {
a = x * 2;
baz();
}
function bar(x) {
a = x / 2;
baz();
}
function baz() {
console.log( a );
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
不管哪一個函數最后觸發（foo()或bar()），它不僅會覆蓋前一個函數對a的賦值，還會重復調用baz()（不太可能是期望的）。
所以，我們可以用一個簡單的門閂來協調互動，僅讓第一個過去：
var a;
function foo(x) {
if (a == undefined) {
a = x * 2;
baz();
}
}
function bar(x) {
if (a == undefined) {
a = x / 2;
baz();
}
}
function baz() {
console.log( a );
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", foo );
ajax( "http://some.url.2", bar );
if (a == undefined)條件僅會讓foo()或bar()中的第一個通過，而第二個（以及后續所有的）調用將會被忽略。第二名什么也得不到！
注意： 在所有這些場景中，為了簡化說明的目的我們都用了全局變量，這里我們沒有任何理由需要這么做。只要我們討論中的函數可以訪問變量（通過作用域），它們就可以正常工作。依賴于詞法作用域變量（參見本叢書的 作用域與閉包 ），和這些例子中實質上的全局變量，是這種并發協調形式的一個明顯的缺點。在以后的幾章中，我們會看到其他的在這方面干凈得多的協調方法。
協作
另一種并發協調的表達稱為“協作并發”，它并不那么看重在作用域中通過共享值互動（雖然這依然是允許的！）。它的目標是將一個長時間運行的“進程”打斷為許多步驟或批處理，以至于其他的并發“進程”有機會將它們的操作穿插進事件輪詢隊列。
舉個例子，考慮一個Ajax應答處理器，它需要遍歷一個很長的結果列表來將值變形。我們將使用Array#map(..)來讓代碼短一些：
var res = [];
// `response(..)`從Ajax調用收到一個結果數組
function response(data) {
// 連接到既存的`res`數組上
res = res.concat(
// 制造一個新的變形過的數組，所有的`data`值都翻倍
data.map( function(val){
return val * 2;
} )
);
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", response );
ajax( "http://some.url.2", response );
如果"http://some.url.1"首先返回它的結果，整個結果列表將會一次性映射進res。如果只有幾千或更少的結果記錄，一般來說不是什么大事。但假如有1千萬個記錄，那么就可能會花一段時間運行（在強大的筆記本電腦上花幾秒鐘，在移動設備上花的時間長得多，等等）。
當這樣的“處理”運行時，頁面上沒有任何事情可以發生，包括不能有另一個response(..)調用，不能有UI更新，甚至不能有用戶事件比如滾動，打字，按鈕點擊等。非常痛苦。
所以，為了制造協作性更強、更友好而且不獨占事件輪詢隊列的并發系統，你可以在一個異步批處理中處理這些結果，在批處理的每一步都“讓出”事件輪詢來讓其他等待的事件發生。
這是一個非常簡單的方法：
var res = [];
// `response(..)`從Ajax調用收到一個結果數組
function response(data) {
// 我們一次只處理1000件
var chunk = data.splice( 0, 1000 );
// 連接到既存的`res`數組上
res = res.concat(
// 制造一個新的變形過的數組，所有的`data`值都翻倍
chunk.map( function(val){
return val * 2;
} )
);
// 還有東西要處理嗎？
if (data.length > 0) {
// 異步規劃下一個批處理
setTimeout( function(){
response( data );
}, 0 );
}
}
// ajax(..) 是某個包中任意的Ajax函數
ajax( "http://some.url.1", response );
ajax( "http://some.url.2", response );
我們以每次最大1000件作為一個塊兒處理數據。這樣，我們保證每個“進程”都是短時間運行的，即便這意味著會有許多后續的“進程”，在事件輪詢隊列上的穿插將會給我們一個響應性（性能）強得多的網站/應用程序。
當然，我們沒有對任何這些“進程”的順序進行互動協調，所以在res中的結果的順序是不可預知的。如果要求順序，你需要使用我們之前討論的互動技術，或者在本書后續章節中介紹的其他技術。
我們使用setTimeout(..0)（黑科技）來異步排程，基本上它的意思是“將這個函數貼在事件輪詢隊列的末尾”。
注意： 從技術上講，setTimeout(..0)沒有直接將一條記錄插入事件輪詢隊列。計時器將會在下一個運行機會將事件插入。比如，兩個連續的setTimeout(..0)調用不會嚴格保證以調用的順序被處理，所以我們可能看到各種時間偏移的情況，使這樣的事件的順序是不可預知的。在Node.js中，一個相似的方式是process.nextTick(..)。不管那將會有多方便（而且通常性能更好），（還）沒有一個直接的方法可以橫跨所有環境來保證異步事件順序。我們會在下一節詳細討論這個話題。
Jobs
在ES6中，在事件輪詢隊列之上引入了一層新概念，稱為“工作隊列（Job queue）”。你最有可能接觸它的地方是在Promises（見第三章）的異步行為中。
不幸的是，它目前是一個沒有公開API的機制，因此要演示它有些兜圈子。我們不得不僅僅在概念上描述它，這樣當我們在第三章中討論異步行為時，你將會理解那些動作行為是如何排程與處理的。
那么，我能找到的考慮它的最佳方式是：“工作隊列”是一個掛靠在事件輪詢隊列的每個tick末尾的隊列。在事件輪詢的一個tick期間內，某些可能發生的隱含異步動作的行為將不會導致一個全新的事件加入事件輪詢隊列，而是在當前tick的工作隊列的末尾加入一個新的記錄（也就是一個Job）。
它好像是在說，“哦，另一件需要我 稍后 去做的事兒，但是保證它在其他任何事情發生之間發生。”
或者，用一個比喻：事件輪詢隊列就像一個游樂園項目，一旦你乘坐完一次，你就不得不去隊尾排隊來乘坐下一次。而工作隊列就像乘坐完后，立即插隊乘坐下一次。
一個Job還可能會導致更多的Job被加入同一個隊列的末尾。所以，一個在理論上可能的情況是，Job“輪詢”（一個Job持續不斷地加入其他Job等）會無限地轉下去，從而拖住程序不能移動到一下一個事件輪詢tick。這與在你的代碼中表達一個長時間運行或無限循環（比如while (true) ..）在概念上幾乎是一樣的。
Job的精神有點兒像setTimeout(..0)黑科技，但以一種定義明確得多的方式實現，而且保證順序： 稍后，但盡快。
讓我們想象一個用于Job排程的API，并叫它schedule(..)。考慮如下代碼：
console.log( "A" );
setTimeout( function(){
console.log( "B" );
}, 0 );
// 理論上的 "Job API"
schedule( function(){
console.log( "C" );
schedule( function(){
console.log( "D" );
} );
} );
你肯能會期望它打印出A B C D，但是它將會打出A C D B，因為Job發生在當前的事件輪詢tick的末尾，而定時器會在 下一個 事件輪詢tick（如果可用的話！）觸發排程。
在第三章中，我們會看到Promises的異步行為是基于Job的，所以搞明白它與事件輪詢行為的聯系是很重要的。
語句排序
我們在代碼中表達語句的順序沒有必要與JS引擎執行它們的順序相同。這可能看起來像是個奇怪的論斷，所以我們簡單地探索一下。
但在我們開始之前，我們應當對一些事情十分清楚：從程序的角度看，語言的規則/文法（參見本叢書的 類型與文法）為語句的順序決定了一個非常可預知、可靠的行為。所以我們將要討論的是在你的JS程序中 應當永遠觀察不到的東西。
警告： 如果你曾經 觀察到 過我們將要描述的編譯器語句重排，那明顯是違反了語言規范，而且無疑是那個JS引擎的Bug——它應當被報告并且修復！但是更常見的是你 懷疑 JS引擎里發生了什么瘋狂的事，而事實上它只是你自己代碼中的一個Bug（可能是一個“競合狀態”）——所以先檢查那里，多檢查幾遍。在JS調試器使用斷點并一行一行地步過你的代碼，將是幫你在 你的代碼 中找出這樣的Bug的最強大的工具。
考慮下面的代碼：
var a, b;
a = 10;
b = 30;
a = a + 1;
b = b + 1;
console.log( a + b ); // 42
這段代碼沒有任何異步表達（除了早先討論的罕見的console異步I/O），所以最有可能的推測是它會一行一行地、從上到下地處理。
但是，JS引擎 有可能，在編譯完這段代碼后（是的，JS是被編譯的——見本叢書的 作用域與閉包）發現有機會通過（安全地）重新安排這些語句的順序來使你的代碼運行得更快。實質上，只要你觀察不到重排，一切都是合理的。
舉個例子，引擎可能會發現如果實際上這樣執行代碼會更快：
var a, b;
a = 10;
a++;
b = 30;
b++;
console.log( a + b ); // 42
或者是這樣：
var a, b;
a = 11;
b = 31;
console.log( a + b ); // 42
或者甚至是：
// 因為`a`和`b`都不再被使用，我們可以內聯而且根本不需要它們!
console.log( 42 ); // 42
在所有這些情況下，JS引擎在它的編譯期間進行著安全的優化，而最終的 可觀察到 的結果將是相同的。
但也有一個場景，這些特殊的優化是不安全的，因而也是不被允許的（當然，不是說它一點兒都沒優化）：
var a, b;
a = 10;
b = 30;
// 我們需要`a`和`b`遞增之前的狀態！
console.log( a * b ); // 300
a = a + 1;
b = b + 1;
console.log( a + b ); // 42
編譯器重排會造成可觀測的副作用（因此絕不會被允許）的其他例子，包括任何帶有副作用的函數調用（特別是getter函數），或者ES6的Proxy對象（參見本叢書的 ES6與未來）。
考慮如下代碼：
function foo() {
console.log( b );
return 1;
}
var a, b, c;
// ES5.1 getter 字面語法
c = {
get bar() {
console.log( a );
return 1;
}
};
a = 10;
b = 30;
a += foo(); // 30
b += c.bar; // 11
console.log( a + b ); // 42
如果不是為了這個代碼段中的console.log(..)語句（只是作為這個例子中觀察副作用的方便形式），JS引擎將會更加自由，如果它想（誰知道它想不想！？），它會重排這段代碼：
// ...
a = 10 + foo();
b = 30 + c.bar;
// ...
多虧JS語義，我們不會觀測到看起來很危險的編譯器語句重排，但是理解源代碼被編寫的方式（從上到下）與它在編譯后運行的方式之間的聯系是多么微弱，依然是很重要的。
編譯器語句重排幾乎是并發與互動的微型比喻。作為一個一般概念，這樣的意識可以幫你更好地理解異步JS代碼流問題。
復習
一個JavaScript程序總是被打斷為兩個或更多的代碼塊兒，第一個代碼塊兒 現在 運行，下一個代碼塊兒 稍后 運行，來響應一個事件。雖然程序是一塊兒一塊兒地被執行的，但它們都共享相同的程序作用域和狀態，所以對狀態的每次修改都是在前一個狀態之上的。
不論何時有事件要運行，事件輪詢 將運行至隊列為空。事件輪詢的每次迭代稱為一個“tick”。用戶交互，IO，和定時器會將事件在事件隊列中排隊。
在任意給定的時刻，一次只有一個隊列中的事件可以被處理。當事件執行時，他可以直接或間接地導致一個或更多的后續事件。
并發是當兩個或多個事件鏈條隨著事件相互穿插，因此從高層的角度來看，它們在 同時 運行（即便在給定的某一時刻只有一個事件在被處理）。
在這些并發“進程”之間進行某種形式的互動協調通常是有必要的，比如保證順序或防止“競合狀態”。這些“進程”還可以 協作：通過將它們自己打斷為小的代碼塊兒來允許其他“進程”穿插。
