[[406283]]

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

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

具體到實(shí)處，則可以從用戶體驗(yàn)和資源分配這兩個(gè)方面說起。

用戶體驗(yàn)

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

資源分配

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

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

單線程順序執(zhí)行任務(wù)的方式比較符合編程人員按順序思考的思維方式。它依然是最主流的編程方式，因?yàn)樗子诒磉_(dá)。但是串行執(zhí)行的缺點(diǎn)在于性能，任意一個(gè)略慢的任務(wù)都會(huì)導(dǎo)致后續(xù)執(zhí)行代碼被阻塞。在計(jì)算機(jī)資源中，通常I/O與CPU計(jì)算之間是可以并行進(jìn)行的。但是同步的編程模型導(dǎo)致的問題是，I/O的進(jìn)行會(huì)讓后續(xù)任務(wù)等待，這造成資源不能被更好地利用。

單線程同步編程模型會(huì)因阻塞I/O導(dǎo)致硬件資源得不到更優(yōu)的使用。多線程編程模型也因?yàn)榫幊讨械乃梨i、狀態(tài)同步等問題讓開發(fā)人員頭疼。

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

異步I/O可以算作Node的特色，因?yàn)樗鞘讉€(gè)大規(guī)模將異步I/O應(yīng)用在應(yīng)用層上的平臺(tái)，它力求在單線程上將資源分配得更高效。為了彌補(bǔ)單線程無法利用多核CPU的缺點(diǎn)，Node提供了類似前端瀏覽器中WebWorkers的子進(jìn)程，該子進(jìn)程可以通過工作進(jìn)程高效地利用CPU和I/O。

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

下圖為異步I/O的調(diào)用示意圖。

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

異步與非阻塞聽起來似乎是同一回事。從實(shí)際效果而言，異步和非阻塞都達(dá)到了我們并行I/O的目的。但是從計(jì)算機(jī)內(nèi)核I/O而言，異步/同步和阻塞/非阻塞實(shí)際上是兩回事。

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

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

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

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

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

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

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

4.可以說下什么是輪詢技術(shù)嗎?

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

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

read

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

select

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

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

poll

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

epoll

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

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

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

有啊。

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

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

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

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

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

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

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

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

事件循環(huán)

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

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

觀察者

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

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

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

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

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

請求對象

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

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

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

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

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

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

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

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

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

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

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

QueueUserWorkItem(& uv_fs_thread_proc, req, WT_EXECUTEDEFAULT) 

QueueUserWorkItem()方法接受3個(gè)參數(shù)：第一個(gè)參數(shù)是將要執(zhí)行的方法的引用，這里引用的是uv_fs_thread_proc，第二個(gè)參數(shù)是uv_fs_thread_proc方法運(yùn)行時(shí)所需要的參數(shù);第三個(gè)參數(shù)是執(zhí)行的標(biāo)志。當(dāng)線程池中有可用線程時(shí)，我們會(huì)調(diào)用uv_fs_thread_proc()方法。

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

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

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

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

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

如下圖所示。

下面是詳細(xì)講解：

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

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

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

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

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

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

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

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

并不是，這些是異步API。

這一部分也值得略微關(guān)注一下。

定時(shí)器

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

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

process.nextTick()

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

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

由于事件循環(huán)自身的特點(diǎn)，定時(shí)器的精確度不夠。而事實(shí)上，采用定時(shí)器需要?jiǎng)佑眉t黑樹，創(chuàng)建定時(shí)器對象和迭代等操作，而setTimeout(fn, 0)的方式較為浪費(fèi)性能。實(shí)際上，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(); 
    } 
}; 

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

setImmediate()

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

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

上述代碼的輸出結(jié)果如下：

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

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

其結(jié)果完全一樣：

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

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

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

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

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

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

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

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