摘要：異步和事件驅動注本文是對眾多博客的學習和總結，可能存在理解錯誤。接觸有兩個月，對的兩大特性一直有點模糊，即異步和事件驅動。

注：本文是對眾多博客的學習和總結，可能存在理解錯誤。請帶著懷疑的眼光，同時如果有錯誤希望能指出。

接觸nodejs有兩個月，對nodejs的兩大特性一直有點模糊，即異步IO和事件驅動。通過對《深入淺出nodejs》和幾篇博客的閱讀以后，有了大致的了解，總結一下。

在開始之前，先來看幾個簡單例子，這也是我在使用nodejs時候遇到的幾個比較困惑的例子。

var fs = require("fs");
var debug = require("debug")("example1");

debug("begin");

setTimeout(function(){
    debug("timeout1");
});

setTimeout(function(){
    debug("timeout2");
});

debug("end");
/** 運行結果
Sat, 21 May 2016 08:41:09 GMT example1 begin
Sat, 21 May 2016 08:41:09 GMT example1 end
Sat, 21 May 2016 08:41:09 GMT example1 timeout1
Sat, 21 May 2016 08:41:09 GMT example1 timeout2
*/

question 1

為何timeout1和timeout2的結果會在end后面？

var fs = require("fs");
var debug = require("debug")("example2");

debug("begin");

setTimeout(function(){
    debug("timeout1");
});

setTimeout(function(){
    debug("timeout2");
});

debug("end");

while(true);
/**  運行結果
Sat, 21 May 2016 08:45:47 GMT example2 begin
Sat, 21 May 2016 08:45:47 GMT example2 end
*/

question 2

為何timeout1和timeout2沒有輸出到終端？while(true)到底阻塞了什么？

var fs = require("fs");
var debug = require("debug")("example3");

debug("begin");

setTimeout(function(){
    debug("timeout1");
    while (true);
});

setTimeout(function(){
    debug("timeout2");
});

debug("end");
/**  運行結果
Sat, 21 May 2016 08:49:12 GMT example3 begin
Sat, 21 May 2016 08:49:12 GMT example3 end
Sat, 21 May 2016 08:49:12 GMT example3 timeout1
*/

question 3

為什么timeout1中回調函數會阻塞timeout2中的回調函數的執行？

var fs = require("fs");
var debug = require("debug")("example4");

debug("begin");

setTimeout(function(){
    debug("timeout1");
    /**
     * 模擬計算密集
     */
    for(var i = 0 ; i < 1000000 ; ++i){
        for(var j = 0 ; j < 100000 ; ++j);
    }
});

setTimeout(function(){
    debug("timeout2");
});

debug("end");
/**
Sat, 21 May 2016 08:53:27 GMT example4 begin
Sat, 21 May 2016 08:53:27 GMT example4 end
Sat, 21 May 2016 08:53:27 GMT example4 timeout1
Sat, 21 May 2016 08:54:09 GMT example4 timeout2  //注意這里的時間晚了好久
*/

question 4

和上面的問題一樣，為何timeout1的計算密集型工作將會阻塞timeout2的回調函數的執行？

var fs = require("fs");
var debug = require("debug")("example5");

debug("begin");

fs.readFile("package.json","utf-8",function(err,data){
    if(err)  
        debug(err);
    else
        debug("get file content");
});

setTimeout(function(){
    debug("timeout2");
});

debug("end");
/** 運行結果
Sat, 21 May 2016 08:59:14 GMT example5 begin
Sat, 21 May 2016 08:59:14 GMT example5 end
Sat, 21 May 2016 08:59:14 GMT example5 timeout2
Sat, 21 May 2016 08:59:14 GMT example5 get file content
*/

question 5

為何讀取文件的IO操作不會阻塞timeout2的執行？

接下來我們就帶著上面幾個疑惑去理解nodejs中的異步IO和事件驅動是如何工作的。

首先來理解幾個容易混淆的概念，阻塞IO(blocking I/O)和非阻塞IO(non-blocking I/O)，同步IO(synchronous I/O)和異步IO(synchronous I/O)。

博主一直天真的以為非阻塞I/O就是異步I/O T_T，apue一直沒有讀懂。

簡單來說，阻塞I/O就是當用戶發一個讀取文件描述符的操作的時候，進程就會被阻塞，直到要讀取的數據全部準備好返回給用戶，這時候進程才會解除block的狀態。

那非阻塞I/O呢，就與上面的情況相反，用戶發起一個讀取文件描述符操作的時，函數立即返回，不作任何等待，進程繼續執行。但是程序如何知道要讀取的數據已經準備好了呢？最簡單的方法就是輪詢。

除此之外，還有一種叫做IO多路復用的模式，就是用一個阻塞函數同時監聽多個文件描述符，當其中有一個文件描述符準備好了，就馬上返回，在linux下，select,poll,epoll都提供了IO多路復用的功能。

那么同步I/O和異步I/O又有什么區別么？是不是只要做到非阻塞IO就可以實現異步I/O呢？

其實不然。

同步I/O(synchronous I/O)做I/O operation的時候會將process阻塞,所以阻塞I/O，非阻塞I/O，IO多路復用I/O都是同步I/O。

異步I/O(asynchronous I/O)做I/O opertaion的時候將不會造成任何的阻塞。

非阻塞I/O都不阻塞了為什么不是異步I/O呢？其實當非阻塞I/O準備好數據以后還是要阻塞住進程去內核拿數據的。所以算不上異步I/O。

這里借一張圖(圖來自這里)來說明他們之間的區別

][1]

更多IO更多的詳細內容可以在這里找到:

Linux IO模式及 select、poll、epoll詳解

select / poll / epoll: practical difference for system architects

事件驅動(event-driven)是nodejs中的第二大特性。何為事件驅動呢？簡單來說，就是通過監聽事件的狀態變化來做出相應的操作。比如讀取一個文件，文件讀取完畢，或者文件讀取錯誤，那么就觸發對應的狀態，然后調用對應的回掉函數來進行處理。

那么線程驅動編程和事件驅動編程之間的區別是什么呢？

線程驅動就是當收到一個請求的時候，將會為該請求開一個新的線程來處理請求。一般存在一個線程池，線程池中有空閑的線程，會從線程池中拿取線程來進行處理，如果線程池中沒有空閑的線程，新來的請求將會進入隊列排隊，直到線程池中空閑線程。

事件驅動就是當進來一個新的請求的時，請求將會被壓入隊列中，然后通過一個循環來檢測隊列中的事件狀態變化，如果檢測到有狀態變化的事件，那么就執行該事件對應的處理代碼，一般都是回調函數。

對于事件驅動編程來說，如果某個時間的回調函數是計算密集型，或者是阻塞I/O,那么這個回調函數將會阻塞后面所有事件回調函數的執行。這一點尤為重要。

上面介紹了那么多的概念，現在我們來看看nodejs中的事件驅動和異步I/O是如何實現的.

nodejs是單線程(single thread)運行的，通過一個事件循環(event-loop)來循環取出消息隊列(event-queue)中的消息進行處理,處理過程基本上就是去調用該消息對應的回調函數。消息隊列就是當一個事件狀態發生變化時，就將一個消息壓入隊列中。

nodejs的時間驅動模型一般要注意下面幾個點：

因為是單線程的，所以當順序執行js文件中的代碼的時候，事件循環是被暫停的。

當js文件執行完以后，事件循環開始運行，并從消息隊列中取出消息，開始執行回調函數

因為是單線程的，所以當回調函數被執行的時候，事件循環是被暫停的

當涉及到I/O操作的時候，nodejs會開一個獨立的線程來進行異步I/O操作，操作結束以后將消息壓入消息隊列。

下面我們從一個簡單的js文件入手，來看看 nodejs是如何執行的。

var fs = require("fs");
var debug = require("debug")("example1");

debug("begin");

fs.readFile("package.json","utf-8",function(err,data){
    if(err)  
        debug(err);
    else
        debug("get file content");
});

setTimeout(function(){
    debug("timeout2");
});

debug("end"); // 運行到這里之前，事件循環是暫停的

同步執行debug("begin")

異步調用fs.readFile()，此時會開一個新的線程去進行異步I/O操作

異步調用setTimeout()，馬上將超時信息壓入到消息隊列中

同步調用debug("end")

開啟事件循環，彈出消息隊列中的信息(目前是超時信息)

然后執行信息對應的回調函數(事件循環又被暫停)

回調函數執行結束后，開始事件循環(目前消息隊列中沒有任何東西，文件還沒讀完)

異步I/O讀取文件完畢，將消息壓入消息隊列(消息中含有文件內容或者是出錯信息)

事件循環取得消息，執行回調

程序退出。

這里借一張圖來說明nodejs的事件驅動模型（圖來自這里）
][2]

這里最后要說的一點就是如何手動將一個函數推入隊列,nodejs為我們提供了幾個比較方便的方法:

setTimeout()

process.nextTick()

setImmediate()

nodejs中的異步I/O的操作是通過libuv這個庫來實現的，包含了window和linux下面的異步I/O實現，博主也沒有研究過這個庫，感興趣的讀者可以移步到這里

好，到目前為止，已經可以回答上面的問題了

question 1

為何timeout1和timeout2的結果會在end后面？

answer 1

因為此時timeout1和timeout2只是被異步函數推入到了隊列中，事件循環還是暫停狀態

question 2

為何timeout1和timeout2沒有輸出到終端？while(true)到底阻塞了什么？

answer 2

因為此處直接阻塞了事件循環，還沒開始，就已經被阻塞了

question 3,4

為什么timeout1中回調函數會阻塞timeout2中的回調函數的執行？

為何timeout1的計算密集型工作將會阻塞timeout2的回調函數的執行？

answer 3,4

因為該回調函數執行返回事件循環才會繼續執行，回調函數將會阻塞事件循環的運行

question 5

為何讀取文件的IO操作不會阻塞timeout2的執行？

answer 5

因為IO操作是異步的，會開啟一個新的線程，不會阻塞到事件循環

參考文獻：

What exactly is a Node.js event loop tick?

What is the difference between a thread-based server and an event-based server?

Some confusion about nodejs threads

The JavaScript Event Loop: Explained

poll vs select vs event-based

Linux IO模式及 select、poll、epoll詳解