[[406283]]

我嘗試用一種自問自答的方式記下筆記，就像面試一樣，我自個兒覺得有意思極了，希望你也喜歡

1.為什么要異步I/O?

具體到實處，則可以從用戶體驗和資源分配這兩個方面說起。

用戶體驗

與前端JavaScript在單線程上執(zhí)行，而且它還與UI渲染共用一個線程 一樣。JavaScript在執(zhí)行的時候UI渲染和響應是處于停滯狀態(tài)的。那么，在node中，假設此時不使用異步io，那么當一個io在執(zhí)行的時候，另一個io的執(zhí)行必須等待前一個io執(zhí)行完畢才可以。那么速度就會慢很多，需要認識到只有后端能夠快速響應資源，才能讓前端的體驗變好。

資源分配

我們首先需要知道計算機在發(fā)展過程中將組件進行了抽象，分為I/O設備和計算設備。

如果創(chuàng)建多線程的開銷小于并行執(zhí)行，那么多線程的方式是首選的。多線程的代價在于創(chuàng)建線程和執(zhí)行期線程上下文切換的開銷較大。另外，在復雜的業(yè)務中，多線程編程經(jīng)常面臨鎖、狀態(tài)同步等問題，這是多線程被詬病的主要原因。但是多線程在多核CPU上能夠有效提升CPU的利用率，這個優(yōu)勢是毋庸置疑的。

單線程順序執(zhí)行任務的方式比較符合編程人員按順序思考的思維方式。它依然是最主流的編程方式，因為它易于表達。但是串行執(zhí)行的缺點在于性能，任意一個略慢的任務都會導致后續(xù)執(zhí)行代碼被阻塞。在計算機資源中，通常I/O與CPU計算之間是可以并行進行的。但是同步的編程模型導致的問題是，I/O的進行會讓后續(xù)任務等待，這造成資源不能被更好地利用。

單線程同步編程模型會因阻塞I/O導致硬件資源得不到更優(yōu)的使用。多線程編程模型也因為編程中的死鎖、狀態(tài)同步等問題讓開發(fā)人員頭疼。

Node在兩者之間給出了它的方案：利用單線程，遠離多線程死鎖、狀態(tài)同步等問題;利用異步I/O，讓單線程遠離阻塞，以更好地使用CPU。

異步I/O可以算作Node的特色，因為它是首個大規(guī)模將異步I/O應用在應用層上的平臺，它力求在單線程上將資源分配得更高效。為了彌補單線程無法利用多核CPU的缺點，Node提供了類似前端瀏覽器中WebWorkers的子進程，該子進程可以通過工作進程高效地利用CPU和I/O。

異步I/O的提出是期望I/O的調用不再阻塞后續(xù)運算，將原有等待I/O完成的這段時間分配給其余需要的業(yè)務去執(zhí)行。

下圖為異步I/O的調用示意圖。

2.說到異步IO，我也經(jīng)常聽到非阻塞IO，這兩者是一個東西嗎?

異步與非阻塞聽起來似乎是同一回事。從實際效果而言，異步和非阻塞都達到了我們并行I/O的目的。但是從計算機內核I/O而言，異步/同步和阻塞/非阻塞實際上是兩回事。

操作系統(tǒng)內核對于I/O只有兩種方式：阻塞與非阻塞。在調用阻塞I/O時，應用程序需要等待I/O完成才返回結果，如圖所示。

阻塞I/O的一個特點是調用之后一定要等到系統(tǒng)內核層面完成所有操作后，調用才結束。以讀取磁盤上的一段文件為例，系統(tǒng)內核在完成磁盤尋道、讀取數(shù)據(jù)、復制數(shù)據(jù)到內存中之后，這個調用才結束。

阻塞I/O造成CPU等待I/O，浪費等待時間，CPU的處理能力不能得到充分利用。為了提高性能，內核提供了非阻塞I/O。非阻塞I/O跟阻塞I/O的差別為調用之后會立即返回，如圖所示。

這個讓我想起直接打印狀態(tài)為pending的promise對象，也是可以打印出來的，這個就是異步吧，雖然狀態(tài)還沒變?yōu)閞esolved或者rejected，也一樣返回了。

非阻塞I/O返回之后，CPU的時間片可以用來處理其他事務，此時的性能提升是明顯的。

3.這樣的話根本無法返回完整的數(shù)據(jù)，怎么辦?

層期望的數(shù)據(jù)，而僅僅是當前調用的狀態(tài)。為了獲取完整的數(shù)據(jù)，應用程序需要重復調用I/O操作來確認是否完成。這種重復調用判斷操作是否完成的技術叫做輪詢。

4.可以說下什么是輪詢技術嗎?

任意技術都并非完美的。阻塞I/O造成CPU等待浪費，非阻塞帶來的麻煩卻是需要輪詢去確認是否完全完成數(shù)據(jù)獲取，它會讓CPU處理狀態(tài)判斷，是對CPU資源的浪費。

輪詢技術主要包括這幾種：read、select、poll、epoll。

read

它是最原始、性能最低的一種，通過重復調用來檢查I/O的狀態(tài)來完成完整數(shù)據(jù)的讀取。在得到最終數(shù)據(jù)前，CPU一直耗用在等待上。下圖為通過read進行輪詢的示意圖。

select

它是在read的基礎上改進的一種方案，通過對文件描述符上的事件狀態(tài)來進行判斷。下圖為通過select進行輪詢的示意圖。

select輪詢具有一個較弱的限制，那就是由于它采用一個1024長度的數(shù)組來存儲狀態(tài)，所以它最多可以同時檢查1024個文件描述符。

poll

該方案較select有所改進，采用鏈表的方式避免數(shù)組長度的限制，其次它能避免不需要的檢查。但是當文件描述符較多的時候，它的性能還是十分低下的。下圖為通過poll實現(xiàn)輪詢的示意圖，它與select相似，但性能限制有所改善。

epoll

該方案是Linux下效率最高的I/O事件通知機制，在進入輪詢的時候如果沒有檢查到I/O事件，將會進行休眠，直到事件發(fā)生將它喚醒。它是真實利用了事件通知、執(zhí)行回調的方式，而不是遍歷查詢，所以不會浪費CPU，執(zhí)行效率較高。下圖為通過epoll方式實現(xiàn)輪詢的示意圖。

輪詢技術滿足了非阻塞I/O確保獲取完整數(shù)據(jù)的需求，但是對于應用程序而言，它仍然只能算是一種同步，因為應用程序仍然需要等待I/O完全返回，依舊花費了很多時間來等待。等待期間，CPU要么用于遍歷文件描述符的狀態(tài)，要么用于休眠等待事件發(fā)生。結論是它不夠好。

5.盡管epoll已經(jīng)利用了事件來降低CPU的耗用，但是休眠期間CPU幾乎是閑置的，對于當前線程而言利用率不夠。那么，是否有一種理想的異步I/O呢?

有啊。

我們期望的完美的異步I/O應該是應用程序發(fā)起非阻塞調用，無須通過遍歷或者事件喚醒等方式輪詢，可以直接處理下一個任務，只需在I/O完成后通過信號或回調將數(shù)據(jù)傳遞給應用程序即可

幸運的是，在Linux下存在這樣一種方式，它原生提供的一種異步I/O方式(AIO)就是通過信號或回調來傳遞數(shù)據(jù)的。

但不幸的是，只有Linux下有，而且它還有缺陷——AIO僅支持內核I/O中的O_DIRECT方式讀取，導致無法利用系統(tǒng)緩存。

6.現(xiàn)實的異步I/O是怎么實現(xiàn)的?

現(xiàn)實比理想要骨感一些，但是要達成異步I/O的目標，并非難事。前面我們將場景限定在了單線程的狀況下，多線程的方式會是另一番風景。通過讓部分線程進行阻塞I/O或者非阻塞I/O加輪詢技術來完成數(shù)據(jù)獲取，讓一個線程進行計算處理，通過線程之間的通信將I/O得到的數(shù)據(jù)進行傳遞，這就輕松實現(xiàn)了異步I/O(盡管它是模擬的)，示意圖如圖。

另一個需要強調的地方在于我們時常提到Node是單線程的，這里的單線程僅僅只是JavaScript執(zhí)行在單線程中罷了。在Node中，無論是*nix還是Windows平臺，內部完成I/O任務的另有線程池。

7.以上是系統(tǒng)對異步IO的實現(xiàn)，那node中是怎么實現(xiàn)異步IO的

完成整個異步I/O環(huán)節(jié)的有事件循環(huán)、觀察者、線程池和請求對象等。

事件循環(huán)

首先，我們著重強調一下Node自身的執(zhí)行模型——事件循環(huán)，正是它使得回調函數(shù)十分普遍。

在進程啟動時，Node便會創(chuàng)建一個類似于while(true)的循環(huán)，每執(zhí)行一次循環(huán)體的過程我們稱為Tick。每個Tick的過程就是查看是否有事件待處理，如果有，就取出事件及其相關的回調函數(shù)。如果存在關聯(lián)的回調函數(shù)，就執(zhí)行它們。然后進入下個循環(huán)，如果不再有事件處理，就退出進程。流程圖如圖

觀察者

在每個Tick的過程中，如何判斷是否有事件需要處理呢?這里必須要引入的概念是觀察者。每個事件循環(huán)中有一個或者多個觀察者，而判斷是否有事件要處理的過程就是向這些觀察者詢問是否有要處理的事件。

這個過程就如同飯館的廚房，廚房一輪一輪地制作菜肴，但是要具體制作哪些菜肴取決于收銀臺收到的客人的下單。廚房每做完一輪菜肴，就去問收銀臺的小妹，接下來有沒有要做的菜，如果沒有的話，就下班打烊了。

在這個過程中，收銀臺的小妹就是觀察者，她收到的客人點單就是關聯(lián)的回調函數(shù)。當然，如果飯館經(jīng)營有方，它可能有多個收銀員，就如同事件循環(huán)中有多個觀察者一樣。收到下單就是一個事件，一個觀察者里可能有多個事件。

瀏覽器采用了類似的機制。事件可能來自用戶的點擊或者加載某些文件時產生，而這些產生的事件都有對應的觀察者。在Node中，事件主要來源于網(wǎng)絡請求、文件I/O等，這些事件對應的觀察者有文件I/O觀察者、網(wǎng)絡I/O觀察者等。觀察者將事件進行了分類。

事件循環(huán)是一個典型的生產者/消費者模型。異步I/O、網(wǎng)絡請求等則是事件的生產者，源源不斷為Node提供不同類型的事件，這些事件被傳遞到對應的觀察者那里，事件循環(huán)則從觀察者那里取出事件并處理。

請求對象

我們可以先看這張圖，大致了解一下node中異步io的實現(xiàn)，然后在看下面的分析。

由于下面的講解中會引用到內部的一些方法，要記住這些方法是很困難的，所以我建議不必深究這些方法是怎么寫的，只要能夠弄清楚這張圖的流程就好

我們將通過解釋Windows下異步I/O(利用IOCP實現(xiàn))的簡單例子來探尋從JavaScript代碼到系統(tǒng)內核之間都發(fā)生了什么。對于一般的(非異步)回調函數(shù)，函數(shù)由我們自行調用，如下所示：

var forEach = function (list, callback) { 
    for (var i = 0; i < list.length; i++) { 
        callback(list[i], i, list); 
    } 
}; 

對于Node中的異步I/O調用而言，回調函數(shù)卻不由開發(fā)者來調用。那么從我們發(fā)出調用后，到回調函數(shù)被執(zhí)行，中間發(fā)生了什么呢?事實上，從JavaScript發(fā)起調用到內核執(zhí)行完I/O操作的過渡過程中，存在一種中間產物，它叫做請求對象。

下面我們以最簡單的fs.open()方法來作為例子，探索Node與底層之間是如何執(zhí)行異步I/O調用以及回調函數(shù)究竟是如何被調用執(zhí)行的：

fs.open = function (path, flags, mode, callback) { 
    // ... 
    binding.open(pathModule._makeLong(path), 
        stringToFlags(flags), 
        mode, 
        callback); 
}; 

fs.open()的作用是根據(jù)指定路徑和參數(shù)去打開一個文件，從而得到一個文件描述符，這是后續(xù)所有I/O操作的初始操作。從前面的代碼中可以看到，JavaScript層面的代碼通過調用C++核心模塊進行下層的操作。

從JavaScript調用Node的核心模塊，核心模塊調用C++內建模塊，內建模塊通過libuv進行系統(tǒng)調用，這是Node里經(jīng)典的調用方式。這里libuv作為封裝層，有兩個平臺的實現(xiàn)，實質上是調用了uv_fs_open()方法。在uv_fs_open()的調用過程中，我們創(chuàng)建了一個FSReqWrap請求對象。從JavaScript層傳入的參數(shù)和當前方法都被封裝在這個請求對象中，其中我們最為關注的回調函數(shù)則被設置在這個對象的oncomplete_sym屬性上：

req_wrap->object_->Set(oncomplete_sym, callback); 

對象包裝完畢后，在Windows下，則調用QueueUserWorkItem()方法將這個FSReqWrap對象推入線程池中等待執(zhí)行，該方法的代碼如下所示：

QueueUserWorkItem(& uv_fs_thread_proc, req, WT_EXECUTEDEFAULT) 

QueueUserWorkItem()方法接受3個參數(shù)：第一個參數(shù)是將要執(zhí)行的方法的引用，這里引用的是uv_fs_thread_proc，第二個參數(shù)是uv_fs_thread_proc方法運行時所需要的參數(shù);第三個參數(shù)是執(zhí)行的標志。當線程池中有可用線程時，我們會調用uv_fs_thread_proc()方法。

uv_fs_thread_proc()方法會根據(jù)傳入?yún)?shù)的類型調用相應的底層函數(shù)。以uv_fs_open()為例，實際上調用fs__open()方法。

至此，JavaScript調用立即返回，由JavaScript層面發(fā)起的異步調用的第一階段就此結束。JavaScript線程可以繼續(xù)執(zhí)行當前任務的后續(xù)操作。當前的I/O操作在線程池中等待執(zhí)行，不管它是否阻塞I/O，都不會影響到JavaScript線程的后續(xù)執(zhí)行，如此就達到了異步的目的。

請求對象是異步I/O過程中的重要中間產物，所有的狀態(tài)都保存在這個對象中，包括送入線程池等待執(zhí)行以及I/O操作完畢后的回調處理。

8.So嘎，上面講得是異步方法的調用，也就是fs.open這個方法的調用，那后面的io操作以及回調函數(shù)的執(zhí)行呢?

簡單的回答就是：調用fs.open這個方法之后就會獲得一個io讀取操作，然后把這個操作放入到線程池，等待有空的線程來執(zhí)行io的讀取操作，然后得到結果，將數(shù)據(jù)傳遞給回調函數(shù)，再執(zhí)行，再執(zhí)行回調。

如下圖所示。

下面是詳細講解：

組裝好請求對象、送入I/O線程池等待執(zhí)行，實際上完成了異步I/O的第一部分，回調通知是第二部分。

線程池中的I/O操作調用完畢之后，會將獲取的結果儲存在req->result屬性上，然后調用PostQueuedCompletionStatus()通知IOCP，告知當前對象操作已經(jīng)完成：

PostQueuedCompletionStatus((loop)->iocp, 0, 0, &((req)->overlapped)) 

PostQueuedCompletionStatus()方法的作用是向IOCP提交執(zhí)行狀態(tài)，并將線程歸還線程池。通過PostQueuedCompletionStatus()方法提交的狀態(tài)，可以通過GetQueuedCompletionStatus()提取。

在這個過程中，我們其實還動用了事件循環(huán)的I/O觀察者。在每次Tick的執(zhí)行中，它會調用IOCP相關的GetQueuedCompletionStatus()方法檢查線程池中是否有執(zhí)行完的請求，如果存在，會將請求對象加入到I/O觀察者的隊列中，然后將其當做事件處理。

I/O觀察者回調函數(shù)的行為就是取出請求對象的result屬性作為參數(shù)，取出oncomplete_sym屬性作為方法，然后調用執(zhí)行，以此達到調用JavaScript中傳入的回調函數(shù)的目的。至此，整個異步I/O的流程完全結束。

事件循環(huán)、觀察者、請求對象、I/O線程池這四者共同構成了Node異步I/O模型的基本要素。

9.setTimeout()、setInterval()、setImmediate()和process.nextTick()也是異步IO嗎?

并不是，這些是異步API。

這一部分也值得略微關注一下。

定時器

setTimeout()和setInterval()與瀏覽器中的API是一致的，分別用于單次和多次定時執(zhí)行任務。它們的實現(xiàn)原理與異步I/O比較類似，只是不需要I/O線程池的參與。調用setTimeout()或者setInterval()創(chuàng)建的定時器會被插入到定時器觀察者內部的一個紅黑樹中。每次Tick執(zhí)行時，會從該紅黑樹中迭代取出定時器對象，檢查是否超過定時時間，如果超過，就形成一個事件，它的回調函數(shù)將立即執(zhí)行。

定時器的問題在于，它并非精確的(在容忍范圍內)。盡管事件循環(huán)十分快，但是如果某一次循環(huán)占用的時間較多，那么下次循環(huán)時，它也許已經(jīng)超時很久了。譬如通過setTimeout()設定一個任務在10毫秒后執(zhí)行，但是在9毫秒后，有一個任務占用了5毫秒的CPU時間片，再次輪到定時器執(zhí)行時，時間就已經(jīng)過期4毫秒。

process.nextTick()

在未了解process.nextTick()之前，很多人也許為了立即異步執(zhí)行一個任務，會這樣調用setTimeout()來達到所需的效果：

setTimeout(function () { 
    // TODO 
}, 0); 

由于事件循環(huán)自身的特點，定時器的精確度不夠。而事實上，采用定時器需要動用紅黑樹，創(chuàng)建定時器對象和迭代等操作，而setTimeout(fn, 0)的方式較為浪費性能。實際上，process.nextTick()方法的操作相對較為輕量，具體代碼如下：

process.nextTick = function (callback) { 
    // on the way out, don't bother. 
    // it won't get fired anyway 
    if (process._exiting) return; 
 
    if (tickDepth >= process.maxTickDepth) 
        maxTickWarn(); 
 
    var tock = { callback: callback }; 
    if (process.domain) tock.domain = process.domain; 
    nextTickQueue.push(tock); 
    if (nextTickQueue.length) { 
        process._needTickCallback(); 
    } 
}; 

每次調用process.nextTick()方法，只會將回調函數(shù)放入隊列中，在下一輪Tick時取出執(zhí)行。定時器中采用紅黑樹的操作時間復雜度為O(lg(n)), nextTick()的時間復雜度為O(1)。相較之下，process.nextTick()更高效。

setImmediate()

setImmediate()方法與process.nextTick()方法十分類似，都是將回調函數(shù)延遲執(zhí)行。在Node v0.9.1之前，setImmediate()還沒有實現(xiàn)，那時候實現(xiàn)類似的功能主要是通過process.nextTick()來完成，該方法的代碼如下所示：

process.nextTick(function () { 
    console.log(’延遲執(zhí)行’); 
}); 
console.log(’正常執(zhí)行’); 

上述代碼的輸出結果如下：

而用setImmediate()實現(xiàn)時，相關代碼如下：

setImmediate(function () { 
    console.log(’延遲執(zhí)行’); 
}); 
console.log(’正常執(zhí)行’); 

其結果完全一樣：

但是兩者之間其實是有細微差別的。將它們放在一起時，又會是怎樣的優(yōu)先級呢。示例代碼如下：

process.nextTick(function () { 
    console.log('nextTick延遲執(zhí)行’); 
  }); 
setImmediate(function () { 
    console.log('setImmediate延遲執(zhí)行’); 
  }); 
console.log(’正常執(zhí)行’); 

其執(zhí)行結果如下：

從結果里可以看到，process.nextTick()中的回調函數(shù)執(zhí)行的優(yōu)先級要高于setImmediate()。這里的原因在于事件循環(huán)對觀察者的檢查是有先后順序的，process.nextTick()屬于idle觀察者，setImmediate()屬于check觀察者。在每一個輪循環(huán)檢查中，idle觀察者先于I/O觀察者，I/O觀察者先于check觀察者。

在具體實現(xiàn)上，process.nextTick()的回調函數(shù)保存在一個數(shù)組中，setImmediate()的結果則是保存在鏈表中。在行為上，process.nextTick()在每輪循環(huán)中會將數(shù)組中的回調函數(shù)全部執(zhí)行完，而setImmediate()在每輪循環(huán)中執(zhí)行鏈表中的一個回調函數(shù)。如下的示例代碼可以佐證：

// 加入兩個nextTick()的回調函數(shù) 
process.nextTick(function () { 
    console.log('nextTick延遲執(zhí)行1'); 
}); 
process.nextTick(function () { 
    console.log('nextTick延遲執(zhí)行2'); 
}); 
// 加入兩個setImmediate()的回調函數(shù) 
setImmediate(function () { 
    console.log('setImmediate延遲執(zhí)行1'); 
    // 進入下次循環(huán) 
    process.nextTick(function () { 
        console.log(’強勢插入’); 
    }); 
}); 
setImmediate(function () { 
    console.log('setImmediate延遲執(zhí)行2'); 
}); 
console.log(’正常執(zhí)行’); 

其執(zhí)行結果如下：

從執(zhí)行結果上可以看出，當?shù)谝粋€setImmediate()的回調函數(shù)執(zhí)行后，并沒有立即執(zhí)行第二個，而是進入了下一輪循環(huán)，再次按process.nextTick()優(yōu)先、setImmediate()次后的順序執(zhí)行。之所以這樣設計，是為了保證每輪循環(huán)能夠較快地執(zhí)行結束，防止CPU占用過多而阻塞后續(xù)I/O調用的情況。