作者：ronaldoliu，騰訊 IEG 后臺開發工程師

或許你也聽說了，摩爾定律失效了。技術的發展不會永遠是指數上升，當芯片的集成度越來越高，高到 1 平方毫米能集成幾億個晶體管時，也就是人們常說的幾納米工藝，我們的半導體行業就踩到天花板了。因為再小下去，晶體管內甚至都快無法通過一個原子了，然后就是不得不面臨量子效應，也就是人們常開玩笑說的——玄學，所謂遇事不決，量子力學。

總而言之，我們的計算機硬件技術發展到了瓶頸期了，CPU 的運行速度幾乎不會再有太多提升了。并且隨著移動互聯網的普及和萬物互聯，我們的應用面臨的請求壓力也越來越大。當硬件能力難以提升時，我們就不得不比以往任何時候都更加需要在軟件和系統層面進行優化。

計算機中有一個非常顯著的特點，就是不同硬件的訪問速度有著天壤之別，這讓幾乎所有的優化都是圍繞這個點來進行。Jeff Dean 曾提出了一組著名的數字來描述這些硬件訪問速度的差別，我們可以通過這個頁面有個直觀的感受。

其中我們需要關注的就是內存訪問和網絡請求以及磁盤訪問的耗時數量級。

由于 CPU 內部做了很多優化（比如流水線），我們可以粗略地認為執行一條指令時間約是 1ns（幾個時鐘周期）。而內存訪問大概是 100ns 的數量級，也就是比執行一條指令慢 100 倍；從 ssd 上隨機讀取一次的時間是 16000ns 級別，而從機械磁盤讀取一次，則需要 2000000ns=2ms。我們無時無刻都在使用的網絡，橫跨大西洋跑一個來回需要的時間約 150000000ns=150ms。你可以看到，相比這些硬件，CPU 的運行速度真的是太快太快了。或許 ns 級單位不直觀，那可以把它換成我們更熟悉的秒來感受下。假如 CPU 執行一條指令是 1 秒，那么訪問內存需要 1 分 40 秒，從 SSD 上隨機讀取一次數據需要 4 小時 24 分鐘，從磁盤讀取一次數據需要 23 天多，一次橫跨大西洋的網絡請求則需要 4.8 年…你現在可以直觀地感受到 CPU 有多么快了吧。

但是快也有快的煩惱，正所謂無敵是多么寂寞。正因為 CPU 速度太快，從 CPU 的角度來說，那其它硬件的速度太慢了（相對論？）。然而關鍵問題是，我們程序的運算幾乎都會依賴這些“慢”硬件，比如在硬盤上讀取某些文件的數據到內存中，再對這些數據進行運算。這就不得不面臨一個問題，由于某條指令依賴于從硬盤加載的數據，CPU 為了執行這條指令就不得不等到硬盤數據加載完。比如要執行answer = a+1，但是 a 存在磁盤上。為了執行一條 1ns 的加法運算，CPU 卻等了 20000000ns，有種等到宇宙盡頭的感覺。

為了應對包括以上這個問題等其它一系列問題，計算機先驅們就設計了支持分時任務的操作系統。我們不說那些老生常談的操作系統歷史了，直接快進到現在，這個分時任務可以粗略地對應成我們常說的線程。操作系統以線程作為最小調度執行單位，線程代表一個獨立的計算任務，當遇到需要費時的操作時，操作系統就把當前線程停下，讓 CPU 去執行別的線程任務，這樣 CPU 就不需要為了要執行一個幾納秒的指令而等上兩百萬納秒。如果操作系統調度得當，可以大大提高 CPU 的利用率，在相同的時間內完成多得多的任務。

在 20 年前，利用多線程就是解決并發的最主流方案。當時最流行的 apache 服務器就是多線程模型，來一個請求就新建一個線程去處理，操作系統負責回收和調度這些線程。這在當年是完全沒有問題的。想想 20 年前，那時候網絡還不發達，用電腦上網的人非常少，網站的功能也非常簡單，因此服務器不會面臨太大的并發訪問。但是隨著時間的推移，尤其是移動互聯網的發展，萬物互聯，大家基本上也都是手機不離手。因而大型網站面臨的用戶訪問量指數級地增大，多線程的不足很快就顯露出來，尤其是在 web 領域。

為什么 web 領域是一個典型呢？因為大多數 web 服務都是 IO 密集型，通常都是：

收到請求?->?查數據庫?->?RPC別的幾個服務?->?組合一下數據?->?返回

在這個過程中，CPU 的參與其實很少，絕大部分時間都是在等待 DB 響應以及等待下游服務的響應。如果使用多線程模型來做 web server，你就會發現，雖然操作系統上有很多線程，但絕大部分線程都處在等待網絡響應或者等待磁盤讀取中，CPU 的利用率依然很低，而且大部分 CPU 都耗在操作系統的線程調度上了。并且，隨著并發請求量的增加，線程的開銷也越來越不容忽視。由于每個線程都有自己獨有的堆棧空間，一般默認是 8M。我們簡單計算一下，光 1000 個線程就會占用 8G 的內存。加上線程切換時的開銷，每次切換，操作系統需要保存當前線程的各種寄存器，后續才能夠恢復線程繼續執行。當線程數量多時，這個開銷也是比較可觀的。

因此，即使多線程是最直觀最容易理解且操作系統天然支持的解決并發的方案，但是由于系統面臨的并發數越來越大，在有限的資源下，我們也不得不尋找更好的解決方法。

終于進入正題了，異步。有一點需要提前說明：

異步的目的不是讓單個任務執行得更快，而是為了讓計算機在相同時間內可以完成更多任務。

其實異步是一個非常復雜而龐大的體系，主要可以分為三個方面：

• 硬件

• 操作系統

• 異步編程范式

毫無疑問硬件是支持異步的根本，但是我們既然標題是“異步編程體系”，拿重心還是在“程序”上，著重聊聊和異步相關的操作系統和編程范式。我在平時和大家聊天以及看網上 blog 的時候會發現，很多人一聊到異步總是很容易把操作系統對異步的支持和異步編程范式混雜在一起。聊到異步最常見的關鍵詞就是：IO 多路復用、epoll、libev、回調地獄、async/await 等等。接下來的文章，我將比較成體系地梳理一下這些概念，讓你真正地從根本上了解異步相關的東西。

初步理解異步的收益

我們從一段最簡單的代碼開始。

let?number?=?read("number.txt"); print(number?+?1);

以上偽代碼從 number.txt 這個文件中讀取一個數字，把它加一然后輸出到屏幕，非常簡單。由于需要一個確定的 number 的值才能進行 number+1 計算，因此要執行 print 前必然要等 read 執行完成（number 才有值）。而 read 是去讀取磁盤上的文件，物理上就需要很長的時間，所以要完成 read+print，總的耗時是不會因為采用同步還是異步就會發生變化。因此：

單個異步任務絕不會比同步任務執行得更快

我們用異步最大的目的是充分利用 CPU 資源。接著上面的例子，假如操作系統提供了一個 read_async 函數，調用它之后能夠立刻返回一個對象，我們后續可以通過這個對象來判斷讀取操作是否完成了。來看看我們的代碼可能會有什么變化：

let?operation?=?read_async("number.txt"); let?number?=?0; while?true?{if?operation.is_finish()?{number?=?operation.get_content();break;} } print(number+1);

似乎變得更糟了！！由于必須要確定 number 的值才能執行 print，因此即使我們立刻拿到一個 operation 對象，我們除了不停地詢問它是否就緒以外，也沒有別的辦法了。CPU 使用率倒是實打實提高了，但是全部都用在了不斷詢問操作是否就緒這個循環上了。和之前的同步代碼相比，做同樣的任務，這樣的異步代碼耗費了相同的時間，卻花費了多得多的 CPU，但是卻并沒有完成更多的任務。這樣寫異步代碼，除了更費電別無它用，還讓代碼變得更復雜！！那異步的價值到底在哪里？

接著上面的例子，我稍微變化一下：

let?a?=?read("qq.com"); let?b?=?read("jd.com"); print(a+b);

假如單個網絡請求耗時 50ms，忽略 print 的耗時，那么上面這段代碼總耗時就是 100ms。我們再用異步看看：

let?op_a?=?read_async("qq.com"); let?op_b?=?read_async("jd.com"); let?a?=?“”; let?b?=?“”; while?true?{if?op_a.is_finish()?{a?=?op_a.get_content();break;} } while?true?{if?op_b.is_finish()?{b?=?op_b.get_content();break;} } print(a+b);

同樣，即使是異步讀取，程序中立刻返回了，但是也是要等到至少 50ms 以后才有結果返回。但是這里差別就出來了。當 CPU 一直循環執行op_a.is_finish()50ms 以后，它終于完成了，此時 a 有了確定的值。然后程序繼續詢問 op_b。這里要注意了，一開始程序連續執行兩個異步請求，這兩個請求同時發送出去了，理想情況下它們可以同時完成。也就是說很可能在 50.001ms 時，op_b 也就緒了。那么這段異步代碼最終執行耗時就是 50ms 左右，相比同步代碼節約了整整一半的時間。

異步并不會讓邏輯上串行的任務變快，只能讓邏輯上可以并行的任務執行更快

雖然以上異步代碼執行速度更快了，但是它也付出了額外的代價。同步代碼雖然執行耗時 100ms，但是 CPU 可以認為一直處于“休眠狀態”；而以上異步代碼中，CPU 卻一直在不斷地詢問操作是否完成。速度更快，但更費電了！！

結合同步的優勢

在上面的同步代碼中，執行一個同步調用，操作系統會把當前線程掛起，等調用成功后再喚醒線程繼續執行，這個過程中 CPU 可以去執行別的線程的任務，而不會空轉。如果沒有別的任務，甚至可以處于半休眠狀態。這說明了一個關鍵問題，即操作系統是完全知道一個磁盤讀取或者網絡調用什么時候完成的，只有這樣它才能在正確的時間喚醒對應線程（操作系統在這里用到的技術就是中斷，這不在本文的范圍內就不多討論了）。既然操作系統有這個能力，那么假如操作系統提供這樣一個函數：

fn?wait_until_get_ready(Operation)?->?Response?{//?阻塞任務，掛起線程，直到operation就緒再喚起線程 }

有了這個函數，那我們的異步代碼就可以這么寫：

let?op_a?=?read_async("qq.com"); let?op_b?=?read_async("jd.com"); let?a?=?wait_until_get_ready(op_a); let?b?=?wait_until_get_ready(op_b); print(a+b);

當調用wait_until_get_ready(op_a)時，op_a 還沒有就緒，操作系統就掛起當前線程，直到 50ms 以后 op_a 就緒。這個過程就像執行同步阻塞代碼一樣不耗費 CPU 資源。然后繼續執行wait_until_get_ready(op_b)，發現 op_b 也就緒了。這樣，我們就可以利用異步代碼，只花費 50ms，并且不花費額外的 CPU 資源，就能完成這個任務，完美！

要讓我們的異步代碼能夠做到這點，其實依賴兩個關鍵因素：

• read_async 把任務交給操作系統后能夠立刻返回，而不會一直阻塞到它執行完畢。通過這個能力，我們可以讓邏輯上沒有依賴的任務并發執行

• wait_until_get_ready 依賴于操作系統的通知能力，不用自己去輪詢，大大節約了 CPU 資源

read_async 和 wait_until_get_ready 是我寫的偽代碼函數，而要實現它們離不開操作系統的底層支撐。這里涉及到非常多的技術，比如常聽說的，select、poll、epoll 這些 Linux 系統支持的方法。kqueue 和 iocp 則分別是 mac 和 windows 版本的"epoll"。不同操作系統實現這些機制的原理也不盡相同的，而且相當的復雜。順便一提，Linux 的 epoll 的設計和性能都不如 windows 的 iocp，最新的 5.1 內核加入了 io_uring，算是向 windows 的 iocp 致敬了，這可能也會給 Linux 異步編程帶來更多新的變化。操作系統和硬件對于異步編程非常重要，不過我決定后面再展開講。

從 0 開始進化成 Javascript

接下來我還是基于上面兩個“異步原語”，來講講是我個人認為在異步編程體系中更為重要而且我們開發者日常接觸最多的部分——異步編程范式。

上面的例子都是非常簡單的場景，而在實際場景中，真正并發幾個沒有關聯的任務然后等待它們執行結束其實是不多見的，大多數是有邏輯依賴關系的。在有邏輯關聯關系的情況下，我們的代碼將會變得非常難以實現，難以閱讀。

我們繼續前面的例子(稍作修改)：

let?op_a?=?read_async("qq.com"); let?op_b?=?read_async("jd.com"); let?a?=?wait_until_get_ready(op_a); write_to("qq.html",?a); let?b?=?wait_until_get_ready(op_b); write_to("jd.html",?b);

之前我們假設每個異步請求耗時都是 50ms，但其實絕大多數時候是無法做出這種假設的，尤其是在網絡環境下，兩個網絡請求很大概率響應時長不一樣，這個很容易理解。當我們發出兩個并發請求后，其實并不知道哪個請求會先響應。我假設 qq.com 的響應時長是 50ms，而 jd.com 的響應時長是 10ms，那么上面的程序會有什么問題呢？

如果我們先let a = wait_until_get_ready(op_a);，此時線程會阻塞直到 op_a 就緒，也就是 50ms 以后才能繼續執行后面的語句。但其實 op_b 早在第 10ms 就已經有響應了，但我們的程序并沒有及時去處理。這里的根本原因就是，我們寫代碼時并不知道每個異步請求會在什么時刻完成，只能按照某種特定順序來執行 wait_until_get_ready 操作，這樣勢必會造成效率低下。怎么辦呢？

這里的問題就出在 wait_until_get_ready 只支持 wait 一個異步操作，不好用。那我們可以考慮給開發操作系統的 Linux Torvads 大爺提需求，系統需要支持這樣的兩個函數：

fn?add_to_wait_list(operations:?Vec<Operation>) fn?wait_until_some_of_them_get_ready()?->Vec<Operation>

通過add_to_wait_list向全局的監聽器注冊需要監聽的異步操作，然后利用wait_until_some_of_them_get_ready，如果沒有事件就緒就阻塞等待，當注冊的異步操作有就緒的了（可能有多個），就喚醒線程并返回一個數組告訴調用方哪些操作就緒了。如果監聽隊列為空時，wait_until_some_of_them_get_ready 不會阻塞而直接返回一個空數組。可以想象，當 Linux Torvads 排了幾個 User Story 讓操作系統支持了這兩個功能并給我提供了庫函數之后，我們的異步代碼就可以更進一步：

let?op_a?=?read_async("qq.com"); let?op_b?=?read_async("jd.com"); add_to_wait_list([op_a,?op_b]); while?true?{let?list?=?wait_until_some_of_them_get_ready();if?list.is_empty()?{break;}for?op?in?list?{if?op.equal(op_a)?{write_to("qq.html",?op.get_content());}?else?if?op.equal(op_b)?{write_to("jd.html",?op.get_content());}} }

通過這種方式，我們的程序能夠及時地響應異步操作，避免盲目地等待，收到一個響應就能立刻輸出一個文件。

不過你如果仔細思考，可以發現這里還有兩個問題。第一是由于異步操作的耗時不同，每次 wait_until_some_of_them_get_ready 返回的可能是一個就緒的異步操作，也可能是多個，因此我們必須要通過一個 while 循環不斷去 wait，直到隊列所有異步操作都就緒為止。第二個問題是，由于返回了一個就緒的異步操作的列表，每個異步操作后續的邏輯可能都不一樣，我們必須要先判斷是什么事件就緒才能執行對應的邏輯，因此不得不做一個很復雜的循環比較。想象一下，如果等待列表里有 1 萬個異步操作，且每個異步操作對應的處理邏輯都不一樣，那我們這個循環判斷的代碼得多么復雜——一萬個 switch case 分支！！所以應該怎么辦呢？

其實有個很簡單的解決辦法：由于 operation 和其就緒后要執行的邏輯是一一對應的，因此我們可以直接把對應的后續執行函數綁定到 operation 上比如:

function?read_async_v1(targetURL:?String,?callback:?Function)?{let?operation?=?read_async("qq.com");operation.callback?=?callback;return?operation; }

這樣我們可以在創建異步任務時就綁定上它后續的邏輯，也就是所謂的回調函數。然后我們 while 循環內部就徹底清爽了，而且避免了一次 O(n)的循環匹配。這是不是就是 C++所謂的動態派發：

let?op_a?=?read_async_v1("qq.com",?function(data)?{send_to("pony@qq.com",?data); }); let?op_b?=?read_async_v1("jd.com",?function(data)?{write_to("jd.html",?data); }); add_to_wait_list([op_a,?op_b]); while?true?{let?list?=?wait_until_some_of_them_get_ready();if?list.is_empty()?{break;}for?op?in?list?{op.callback(op.get_content());} }

這里的關鍵一步是，read_async 返回的 operation 對象需要能夠支持綁定回調函數。

當做到這一步時，其實我們還可以再更進一步，讓 read_async_v1 自己去注冊監聽器：

function?read_async_v2(target,?callback)?{let?operation?=?read_async(target);operation.callback?=?callback;add_to_wait_list([operation]); }

這樣我們的代碼可以更簡化：

read_async_v2("qq.com",?function(data)?{send_to("mahuateng@qq.com",?data); }); read_async_v2("jd.com",?function(data)?{write_to("jd.html",?data); }); while?true?{let?list?=?wait_until_some_of_them_get_ready();if?list.is_empty()?{break;}for?op?in?list?{op.callback(op.get_content());} }

由于我們把后續邏輯都綁定到 operation 上了，每個異步程序都需要在最后執行上述的 while 循環來等待異步事件就緒，然后執行其回調。因此如果我們有機會設計一門編程語言，那就可以把這段代碼放到語言的運行時里，讓用戶不需要每次都在最后加這么一段。經過這個改造后，我們的代碼就變成了：

read_async_v2("qq.com",?function(data)?{send_to("pony@qq.com",?data); }); read_async_v2("jd.com",?function(data)?{write_to("jd.html",?data); });//?編譯器幫我們把while循環自動插到這里 //?或者什么異步框架幫我們做while循環

你看，這是不是就是 javascript 了！！js 的 v8 引擎幫我們執行了 while 循環，也就是 JS 里大家常說的EventLoop。

可以看到，其實我們沒有運用任何黑魔法，只依賴幾個操作系統提供的基本元語就可以很自然地過渡到 Javascript 的異步編程模型。

再簡單回顧一下：

• 為了讓程序在同一時間內處理更多的請求，我們采用多線程。多線程雖然編寫簡單，但是對內存和 CPU 資源消耗大，因此我們考慮利用系統的異步接口進行開發;

• 我不知道異步操作什么時候結束，只能不停的輪詢它的狀態。當有多個異步操作，每個的響應時間都未知，不知道該去先輪詢哪個。我們利用操作系統提供的能力，把異步事件加入全局監聽隊列，然后通過 wait_until_some_of_them_get_ready 來等待任意事件就緒，所謂的 EventLoop；

• 當事件就緒后 EventLoop 不知道該執行什么邏輯，只能進行一個非常復雜的判斷才能確認后續邏輯該執行哪個函數。因此我們給每個異步事件注冊回調函數，這樣 EventLoop 的實現就高效而清爽了;

• 所有異步程序都需要在最后執行 EventLoop 等待事件就緒然后執行回調，因此可以把 EventLoop 這塊邏輯放到語言自身的 runtime 中，不需要每次自己寫。

我們上述利用到的wait_until_some_of_them_get_ready對應到真實的操作系統上，其實就是 Linux 的 epoll，Mac 的 kqueue 以及 windows 的 iocp。其實不止 javascript，C 和 C++很多異步框架也是類似的思路，比如著名的 Redis 使用的 libevent，以及 nodejs 使用的 libuv。這些框架的共同特點就是，它們提供了多種異步的 IO 接口，支持事件注冊以及通過回調來進行異步編程。只是像 C 代碼，由于不支持閉包，基于它們實現的異步程序，實際上比 js 開發的更難以閱讀和調試。

所以根據上述的演進過程，你是不是覺得 js 的異步回調對于編寫異步代碼已經是一個相當高級的編程方式了。不過接下來才是真正的魔鬼！

回調地獄

基于回調開發異步代碼，很快就會遇到臭名昭著的回調地獄。比如：

login(user?=>?{getStatus(status?=>?{getOrder(order?=>?{getPayment(payment?=>?{getRecommendAdvertisements(ads?=>?{setTimeout(()?=>?{alert(ads)},?1000)})})})}) })

以上代碼就是所謂的回調地獄，由于每次異步操作都需要有一個回調函數來執行就緒后的后續邏輯，因此當遇上各個異步操作之前有先后關系時，勢必就要回調套回調。當業務代碼一復雜，回調套回調寫多了，造成代碼難以閱讀和調試，就成了所謂的回調地獄。

JS 圈的大佬們花了很多精力來思考如何解決回調地獄的問題，其中最著名的就是 promise。promise并不是什么可以把同步代碼變異步代碼的黑魔法。它只是一種編程手法，或者你可以理解為一種封裝，并沒有借助操作系統額外的能力。這也是為什么我的標題是“編程范式”，promise 就是一種范式。

再仔細看看我們上面的回調地獄的示例代碼，想想出現這種層層嵌套的本質是什么。說到底，其實就是我們通過回調這種方式來描述“當一個異步操作完成之后接下來該干什么”。多個異步操作有先后關系，因此自然而然形成了回調地獄。既然多個異步操作組成了“串行”邏輯，那么我們能用更“串行”的方式來描述這個邏輯嗎？比如：

login(username,?password).then(user?=>?getStatus(user.id)).then(status?=>?getOrder(status.id)).then(order?=>?getPayment(order.id)).then(payment?=>?getRecommendAdvertisements(payment.total_amount)).then(ads?=>?{/*...*/});

這樣看起來就比層層嵌套的回調直觀一些了，先執行 A 操作，then 執行 B，then 執行 C……邏輯的先后關系一目了然，書寫方式也符合我們人類串行的思維方式。但是這種編程方式怎么實現呢？

回想之前我們實現異步回調時，異步函數會返回一個 operation 對象，這個對象保存了回調函數的函數指針，因此當 EventLoop 發現該 operation 就緒后就可以直接跳轉到對應的回調函數去執行。但是在上述鏈式調用.then 的代碼中，我們調用login(username, pwd).then(...)時，注意是當 login 這個函數已經執行完畢了，才調用的 then。相當于我已經把異步函數提交執行了之后，才來綁定的回調函數。這個能實現嗎？

再回顧一下我們之前的read_async_v2:

function?read_async_v2(target,?callback)?{let?operation?=?read_async(target);operation.callback?=?callback;add_to_wait_list([operation]); }

我們直接在函數內部把 operation 的回調給設置好了，并把 operation 加入監聽隊列。但其實不一定要在這個時候去設置回調函數，只要在 EventLoop 執行之前設置好就行了。基于這個思路我們可以把 operation 保存在一個對象中，后續通過這個對象給 operation 添加回調方法，比如：

function?read_async_v3(target)?{let?operation?=?read_async(target);add_to_wait_list([operation]);return?{then:?function(callback)?{operation.callback?=?callback;},} }//?我們可以這樣 read_async_v3("qq.com").then(logic)

但是這種實現方式只能設置一個回調，不能像之前說的完成鏈式調用。為了支持鏈式調用我們可以這樣：

function?read_async_v4(target)?{let?operation?=?read_async(target);add_to_wait_list([operation]);let?chainableObject?=?{callbacks:?[],then:?function(callback)?{this.callbacks.push(callback);return?this;},run:?function(data)?{let?nextData?=?data;for?cb?in?this.callbacks?{nextData?=?cb(nextData);}}};operation.callback?=?chainableObject.run;return?chainableObject; }//?于是我們可以這樣 read_async_v4("qq.com").then(logic1).then(logic2).then(/*...*/)

如上述代碼，主要的實現思路就是，我們返回一個對象，這個對象保存一個 callback 列表，每次可以通過調用對象的 then 方法新增一個回調。由于 then 方法返回了對象本身，因此可以進行鏈式調用。然后我們把 operation 就緒后的 callback 設置成這個對象的 run 方法，也就是說 EventLoop 調用的其實是這個包裝過的對象的 run 方法，它再來依次執行我們之前通過 then 設置好的回調函數。

看起來大功告成了嗎？不，這里有個嚴重的問題，就是我們的鏈式調用其實是綁定到一個異步調用上的，當這個異步操作就緒后 run 方法會把 then 綁定的所有回調都執行完。如果這些回調里又包含了異步調用，比如我們先請求 qq.com 然后輸出 qq.com 的內容，接著請求 jd.com，然后輸出 jd.com 的內容：

read_async_v4("qq.com").then(data?=>?console.log("qq.com:?${data}")).then((_)?=>?read_async_v4("jd.com")).then(data?=>?console.log("jd.com:?{$data}"))

但是上面這段代碼是有問題的，這三個 then 其實都是 qq.com 的回調，當請求 qq.com 完成時，EventLoop 執行 operation 的 run 方法，然后 run 方法會依次調用這三個回調。當調用到第二個回調時，此時它只是發出了一個對 jd.com 的異步請求然后返回了一個針對 jd.com 的 chainable 對象。因此第三個 then 的入參 data 并不是我們期望的 jd.com 返回的內容，而是一個 chainable 對象。因此最終的輸出可能是：

"qq.com:?<html>....</html>" "jd.com:?[Object]"

過了一會兒 jd.com 請求也完成了，但是發現沒給它設置回調，所以就直接把結果丟棄了。這當然不是我們想要的樣子！正確的寫法應該是：

read_async_v4("qq.com").then(data?=>?console.log("qq.com:?${data}")).then((_)?=>?{read_async_v4("jd.com").then(data?=>?console.log("jd.com:?{$data}")).then((_)?=>?{read_async_v4("baidu.com").then(data?=>?console.log("baidu.com:?${data}"));});});

只有這樣才是真正我們想要的結果，先輸出 qq.com 的內容，在輸出 jd.com 的內容。then 里面如果是異步請求，那么就必須在內部完成 then 的綁定……但是這樣不就又回到回調地獄了嗎？？？一波操作猛如虎，回頭一看原地杵？？？、

其實要解決這個問題很簡單，只需要修改一下 run 方法，當某次回調返回一個 chainableObject，那就把剩下的回調綁定到那個對象上，然后就可以退出了。比如：

function?read_async_v5(target)?{let?operation?=?read_async(target);add_to_wait_list([operation]);let?chainableObject?=?{callbacks:?[],then:?function(callback)?{this.callbacks.push(callback);return?this;},run:?function(data)?{let?nextData?=?data;let?self?=?this;while?self.callbacks.length?>?0?{//?每次從隊首彈出一個回調函數let?cb?=?self.callbacks.pop_front();nextData?=?cb(nextData);//?如果回調返回了一個ChainableObject，那么就把剩下的callback綁定到它上面//?然后就可以終止執行了if?isChainableType(nextData)?{nextData.callbacks?=?self.callbacks;return;}}}};operation.callback?=?chainableObject.run;return?chainableObject; }

這樣之后，我們就可以真正地實現異步的鏈式調用，比如：

read_async_v5("qq.com").then(data?=>?console.log("qq.com:?${data}")).then((_)?=>?read_async_v5("jd.com")).then(data?=>?console.log("jd.com:?{$data}"))

雖然一開始所有的 then 都把回調綁定到對 qq.com 進行異步請求的 operation 上，但這只是暫時的。當執行完第二個回調時，發現它返回了一個 chainableObject，于是就把剩余的 callback 綁定到這個新的對象上，不再繼續執行了。當 jd.com 的請求就緒后，EventLoop 執行它的 operation 的 run 方法，再接著執行后面回調。

如果我們提供一個庫，里面包含了各種異步方法，它們的共同特點是都會返回一個 ChainableObject，這樣以來，我們就能夠利用 then 來組合它們完成我們的業務開發。這就是所謂的異步生態！

比如我們提供一個異步庫，它包含：http_get, http_post, read_fs, write_fs等返回 chainableObject 的方法，那么通過組合它們，我們能夠非常容易地實現復雜的業務邏輯，比如前述的回調地獄可以改寫為：

http_post("/login",?body).then(user?=>?http_get("/order?user_id=${user.id}")).then(order?=>?http_post("/payment",?{oid:?order.id})).then(/*...*/)

看起來是不是和 js 基于 promise 的鏈式調用一模一樣了？

其實我們上述的 chainableObject 就可以看做是 js 中的 promise。區別是，由于 js 一開始全是基于回調的編程模型，各種標準庫內置的異步方法都只能接收回調，為了向后兼容，沒法把那些內置函數改成返回 promise。因此 js 的辦法是提供 promise 的構造方法，把異步函數“包裝”成 promise。如果基于我們 chainableObject 實現，就是這樣的：

function?ChainableObject()?{return?chainableObject?=?{callbacks:?[],then:?function(callback)?{/*同之前，略*/},run:?function(data)?{let?nextData?=?data;if?self.resolveData?!=?null?{nextData?=?self.resolveData;}while?self.callbacks.length?>?0?{//同上，省略}},resolveData:?null,}; }function?Convert2Chainable(targetFunction)?{let?obj?=?new?ChainableObject();function?resolve(data)?{obj.resolveData?=?data;}targetFunction(resolve);return?obj; }

這樣以后，我們可以利用標準庫的老回調式方法寫出這樣的代碼:

Convert2Chainable(resolve?=>?{let?sleep?=?100;setTimeout(()?=>?{resolve(sleep);},?sleep); }).then(data?=>?console.log("sleep:?${data}ms")).then((_)?=>?Convert2Chainable(resolve?=>?{let?sleep?=?200;setTimeout(()?=>?{resolve(sleep);},?sleep); }) .then(data?=>?console.log("sleep:?${data}ms")) .then((_)?=>?Convert2Chainable(resolve?=>?{$.ajax("qq.com",?function(res)?{resolve(res);}); }) .then(data?=>?console.log("qq.com:?${data}"));

這里的關鍵就是，我們通過Convert2Chainable 函數，可以把任意的標準庫內置的異步方法包裝成一個 ChainableObject。ChainableObject 只是我為了解釋清楚異步鏈式調用的具體實現原理而隨意實現的一個對象，它其實就是 js 中的 Promise。具體的實現肯定沒這么簡單，因為 Promise 還有很多處理錯誤的邏輯，但是原理都是一樣的。后續我將不再使用 ChainableObject 這個名詞，轉而使用 Promise，你知道它們是一回事就行了。

小總結

本文中我花了一些篇幅，通過例子帶領大家一步一步看懂異步編程的一些本質原理。你可以清楚地看到，所有的異步任務都是由一個線程發起，所有后續的邏輯都由這個線程來完成。當大量并發請求到來時，我們只用一個線程就能處理這些所有的請求，這就是異步編程的真正價值所在。這也是 nodejs 可以用來做一些后端開發并且能夠達到相當好的性能的重要原因！！我們熟悉的 Redis Nginx 都是基于這樣一套異步編程范式，享受異步帶來的巨大優勢。

And More

但有了 Promise 這種方式，異步編程就大功告成了嗎？其實并沒有……基于 Promise 這樣的鏈式調用只是比回調好懂一點，但和多線程的同步編寫方式相比，也并沒有那么容易讀。并且錯誤的捕獲和傳播也是個問題。下一篇文章我將講一講 Promise 的問題，然后看看我們能夠提出什么樣更加優雅的解決方案——其實就是 async/await。你要做好心理準備，async/await 雖然優雅，它不像 promise 這樣只是一層庫的封裝，async/await 需要和語言的編譯器結合起來，對代碼做一些轉換，要實現它不是一件那么容易的事情。當然也不必害怕，因為它不涉及具體的編譯原理相關內容，只是做了一些代碼生成而已。

另一方面，我們上述的 wait_until_some_of_them_get_ready 函數幫我們屏蔽了太多底層的細節，它其實就是一個異步任務調度器。它是怎么做到的呢？依賴 OS 的能力是必然的，但是調度器本身也需要很大的開發量。調度器本身的實現決定著某種編程語言并發方面的性能優劣。Rust 是性能堪比 C/C++的編程語言，同時提供了 async await 的支持。

最近好文：

認識 MySQL 和 Redis 的數據一致性問題

開發常用的縮寫 你能看懂幾個？

TencentOCR 斬獲 ICDAR 2021 三項冠軍

騰訊程序員視頻號最新視頻

總結

以上是生活随笔為你收集整理的从根本上了解异步编程体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。