一、多線程與單線程

像java、python這個可以具有多線程的語言。多線程同步模式是這樣的，將cpu分成幾個線程，每個線程同步運行。

而node.js采用單線程異步非阻塞模式，也就是說每一個計算獨占cpu，遇到I/O請求不阻塞后面的計算，當I/O完成后，以事件的方式通知，繼續(xù)執(zhí)行計算2。

事件驅(qū)動、異步、單線程、非阻塞I/O，這是我們聽得最多的關(guān)于nodejs的介紹。看到上面的關(guān)鍵字，可能我們會好奇：

為什么在瀏覽器中運行的 Javascript 能與操作系統(tǒng)進行如此底層的交互？

nodejs既然是單線程，如何實現(xiàn)異步、非阻塞I/O？

nodejs全是異步調(diào)用和非阻塞I/O，就真的不用管并發(fā)數(shù)了嗎？

nodejs事件驅(qū)動是如何實現(xiàn)的？和瀏覽器的event loop是一回事嗎？

nodejs擅長什么？不擅長什么？

二、nodejs內(nèi)部揭秘

要弄清楚上面的問題，首先要弄清楚nodejs是怎么工作的。

我們可以看到，Node.js 的結(jié)構(gòu)大致分為三個層次：

1、 Node.js 標準庫，這部分是由 Javascript 編寫的，即我們使用過程中直接能調(diào)用的 API。在源碼中的 lib 目錄下可以看到。

2、 Node bindings，這一層是 Javascript 與底層 C/C++ 能夠溝通的關(guān)鍵，前者通過 bindings 調(diào)用后者，相互交換數(shù)據(jù)。

3、這一層是支撐 Node.js 運行的關(guān)鍵，由 C/C++ 實現(xiàn)。

V8：Google 推出的 Javascript VM，也是 Node.js 為什么使用的是 Javascript 的關(guān)鍵，它為 Javascript 提供了在非瀏覽器端運行的環(huán)境，它的高效是 Node.js 之所以高效的原因之一。

Libuv：它為 Node.js 提供了跨平臺，線程池，事件池，異步 I/O 等能力，是 Node.js 如此強大的關(guān)鍵。

C-ares：提供了異步處理 DNS 相關(guān)的能力。

http_parser、OpenSSL、zlib 等：提供包括 http 解析、SSL、數(shù)據(jù)壓縮等其他的能力。

三、libuv簡介

可以看出，幾乎所有和操作系統(tǒng)打交道的部分都離不開 libuv的支持。libuv也是node實現(xiàn)跨操作系統(tǒng)的核心所在。

四、我們再來看看最開始我拋出的問題

問題一：為什么在瀏覽器中運行的 Javascript 能與操作系統(tǒng)進行如此底層的交互？

舉個簡單的例子，我們想要打開一個文件，并進行一些操作，可以寫下面這樣一段代碼：

var fs = require('fs');

fs.open('./test.txt', "w", function(err, fd) {

//..do something

});

fs.open = function(path, flags, mode, callback) {

// ...

binding.open(pathModule._makeLong(path),

stringToFlags(flags),

mode,

callback);

};

這段代碼的調(diào)用過程大致可描述為：lib/fs.js → src/node_file.cc →uv_fs

從JavaScript調(diào)用Node的核心模塊，核心模塊調(diào)用C++內(nèi)建模塊，內(nèi)建模塊通過 libuv進行系統(tǒng)調(diào)用，這是Node里經(jīng)典的調(diào)用方式。總體來說，我們在 Javascript 中調(diào)用的方法，最終都會通過node-bindings 傳遞到 C/C++ 層面，最終由他們來執(zhí)行真正的操作。Node.js 即這樣與操作系統(tǒng)進行互動。

問題二：nodejs既然是單線程，如何實現(xiàn)異步、非阻塞I/O？

順便回答標題nodejs真的是單線程嗎？其實只有js執(zhí)行是單線程，I/O顯然是其它線程。

js執(zhí)行線程是單線程，把需要做的I/O交給libuv，自己馬上返回做別的事情，然后libuv在指定的時刻回調(diào)就行了。其實簡化的流程就是醬紫的！細化一點，nodejs會先從js代碼通過node-bindings調(diào)用到C/C++代碼，然后通過C/C++代碼封裝一個叫 “請求對象” 的東西交給libuv，這個請求對象里面無非就是需要執(zhí)行的功能+回調(diào)之類的東西，給libuv執(zhí)行以及執(zhí)行完實現(xiàn)回調(diào)。

總結(jié)來說，一個異步 I/O 的大致流程如下：

1、發(fā)起 I/O 調(diào)用

用戶通過 Javascript 代碼調(diào)用 Node 核心模塊，將參數(shù)和回調(diào)函數(shù)傳入到核心模塊；

Node 核心模塊會將傳入的參數(shù)和回調(diào)函數(shù)封裝成一個請求對象；

將這個請求對象推入到 I/O 線程池等待執(zhí)行；

Javascript 發(fā)起的異步調(diào)用結(jié)束，Javascript 線程繼續(xù)執(zhí)行后續(xù)操作。

2、執(zhí)行回調(diào)

I/O 操作完成后，會取出之前封裝在請求對象中的回調(diào)函數(shù)，執(zhí)行這個回調(diào)函數(shù)，以完成 Javascript 回調(diào)的目的。(這里回調(diào)的細節(jié)下面講解)

從這里，我們可以看到，我們其實對 Node.js 的單線程一直有個誤會。事實上，它的單線程指的是自身 Javascript 運行環(huán)境的單線程，Node.js 并沒有給 Javascript 執(zhí)行時創(chuàng)建新線程的能力，最終的實際操作，還是通過 Libuv 以及它的事件循環(huán)來執(zhí)行的。這也就是為什么 Javascript 一個單線程的語言，能在 Node.js 里面實現(xiàn)異步操作的原因，兩者并不沖突。

問題三：nodejs全是異步調(diào)用和非阻塞I/O，就真的不用管并發(fā)數(shù)了嗎？

之前我們就提到了線程池的概念，發(fā)現(xiàn)nodejs并不是單線程的，而且還有并行事件發(fā)生。同時，線程池默認大小是 4 ，也就是說，同時能有4個線程去做文件i/o的工作，剩下的請求會被掛起等待直到線程池有空閑。 所以nodejs對于并發(fā)數(shù)，是由限制的。

線程池的大小可以通過 UV_THREADPOOL_SIZE 這個環(huán)境變量來改變 或者在nodejs代碼中通過 process.env.UV_THREADPOOL_SIZE來重新設(shè)置。

問題四：nodejs事件驅(qū)動是如何實現(xiàn)的？和瀏覽器的event loop是一回事嗎？

event loop是一個執(zhí)行模型，在不同的地方有不同的實現(xiàn)。瀏覽器和nodejs基于不同的技術(shù)實現(xiàn)了各自的event loop。

簡單來說：

nodejs的event是基于libuv，而瀏覽器的event loop則在html5的規(guī)范中明確定義。

libuv已經(jīng)對event loop作出了實現(xiàn)，而html5規(guī)范中只是定義了瀏覽器中event loop的模型，具體實現(xiàn)留給了瀏覽器廠商。

我們上面提到了libuv接過了js傳遞過來的 I/O請求，那么何時來處理回調(diào)呢？

libuv有一個事件循環(huán)(event loop)的機制，來接受和管理回調(diào)函數(shù)的執(zhí)行。

event loop是libuv的核心所在，上面我們提到 js 會把回調(diào)和任務(wù)交給libuv，libuv何時來調(diào)用回調(diào)就是 event loop 來控制的。event loop 首先會在內(nèi)部維持多個事件隊列(或者叫做觀察者 watcher)，比如 時間隊列、網(wǎng)絡(luò)隊列等等，使用者可以在watcher中注冊回調(diào)，當事件發(fā)生時事件轉(zhuǎn)入pending狀態(tài)，再下一次循環(huán)的時候按順序取出來執(zhí)行，而libuv會執(zhí)行一個相當于 while true的無限循環(huán)，不斷的檢查各個watcher上面是否有需要處理的pending狀態(tài)事件，如果有則按順序去觸發(fā)隊列里面保存的事件，同時由于libuv的事件循環(huán)每次只會執(zhí)行一個回調(diào)，從而避免了 競爭的發(fā)生。Libuv的 event loop執(zhí)行圖：

nodejs的event loop分為6個階段，每個階段的作用如下：

timers：執(zhí)行setTimeout() 和 setInterval()中到期的callback。

I/O callbacks：上一輪循環(huán)中有少數(shù)的I/Ocallback會被延遲到這一輪的這一階段執(zhí)行

idle, prepare：僅內(nèi)部使用

poll：最為重要的階段，執(zhí)行I/O callback，在適當?shù)臈l件下會阻塞在這個階段

check：執(zhí)行setImmediate的callback

close callbacks：執(zhí)行close事件的callback，例如socket.on("close",func)

event loop的每一次循環(huán)都需要依次經(jīng)過上述的階段。 每個階段都有自己的callback隊列，每當進入某個階段，都會從所屬的隊列中取出callback來執(zhí)行，當隊列為空或者被執(zhí)行callback的數(shù)量達到系統(tǒng)的最大數(shù)量時，進入下一階段。這六個階段都執(zhí)行完畢稱為一輪循環(huán)。

附帶event loop 源碼：

int uv_run(uv_loop_t* loop, uv_run_mode mode) {

int timeout;

int r;

int ran_pending;

/*

從uv__loop_alive中我們知道event loop繼續(xù)的條件是以下三者之一：

1，有活躍的handles(libuv定義handle就是一些long-lived objects，例如tcp server這樣)

2，有活躍的request

3，loop中的closing_handles

*/

r = uv__loop_alive(loop);

if (!r)

uv__update_time(loop);

while (r != 0 && loop->stop_flag == 0) {

uv__update_time(loop);//更新時間變量，這個變量在uv__run_timers中會用到

uv__run_timers(loop);//timers階段

ran_pending = uv__run_pending(loop);//從libuv的文檔中可知，這個其實就是I/O callback階段,ran_pending指示隊列是否為空

uv__run_idle(loop);//idle階段

uv__run_prepare(loop);//prepare階段

timeout = 0;

/**

設(shè)置poll階段的超時時間，以下幾種情況下超時會被設(shè)為0，這意味著此時poll階段不會被阻塞，在下面的poll階段我們還會詳細討論這個

1，stop_flag不為0

2，沒有活躍的handles和request

3，idle、I/O callback、close階段的handle隊列不為空

否則，設(shè)為timer階段的callback隊列中，距離當前時間最近的那個

**/

if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT)

timeout = uv_backend_timeout(loop);

uv__io_poll(loop, timeout);//poll階段

uv__run_check(loop);//check階段

uv__run_closing_handles(loop);//close階段

//如果mode == UV_RUN_ONCE(意味著流程繼續(xù)向前)時，在所有階段結(jié)束后還會檢查一次timers，這個的邏輯的原因不太明確

if (mode == UV_RUN_ONCE) {

uv__update_time(loop);

uv__run_timers(loop);

}

r = uv__loop_alive(loop);

if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)

break;

}

if (loop->stop_flag != 0)

loop->stop_flag = 0;

return r;

}

這里我們再詳細了解一下poll階段：

poll 階段有兩個主要功能：

1、執(zhí)行下限時間已經(jīng)達到的timers的回調(diào)

2、處理 poll 隊列里的事件。

當event loop進入 poll 階段，并且 沒有設(shè)定的timers(there are no timers scheduled)，會發(fā)生下面兩件事之一：

1、如果 poll 隊列不空，event loop會遍歷隊列并同步執(zhí)行回調(diào)，直到隊列清空或執(zhí)行的回調(diào)數(shù)到達系統(tǒng)上限；

2、如果 poll 隊列為空，則發(fā)生以下兩件事之一：

(1)如果代碼已經(jīng)被setImmediate()設(shè)定了回調(diào), event loop將結(jié)束 poll 階段進入 check 階段來執(zhí)行 check 隊列(里的回調(diào))。

(2)如果代碼沒有被setImmediate()設(shè)定回調(diào)，event loop將阻塞在該階段等待回調(diào)被加入 poll 隊列，并立即執(zhí)行。

但是，當event loop進入 poll 階段，并且 有設(shè)定的timers，一旦 poll 隊列為空(poll 階段空閑狀態(tài))：

event loop將檢查timers,如果有1個或多個timers的下限時間已經(jīng)到達，event loop將繞回 timers 階段。

event loop的一個例子講述：

var fs = require('fs');

function someAsyncOperation (callback) {

// 假設(shè)這個任務(wù)要消耗 95ms

fs.readFile('/path/to/file', callback);

}

var timeoutScheduled = Date.now();

setTimeout(function () {

var delay = Date.now() - timeoutScheduled;

console.log(delay + "ms have passed since I was scheduled");

}, 100);

// someAsyncOperation要消耗 95 ms 才能完成

someAsyncOperation(function () {

var startCallback = Date.now();

// 消耗 10ms...

while (Date.now() - startCallback < 10) {

; // do nothing

}

});

當event loop進入 poll 階段，它有個空隊列(fs.readFile()尚未結(jié)束)。所以它會等待剩下的毫秒，直到最近的timer的下限時間到了。當它等了95ms，fs.readFile()首先結(jié)束了，然后它的回調(diào)被加到 poll的隊列并執(zhí)行——這個回調(diào)耗時10ms。之后由于沒有其它回調(diào)在隊列里，所以event loop會查看最近達到的timer的下限時間，然后回到 timers 階段，執(zhí)行timer的回調(diào)。

所以在示例里，回調(diào)被設(shè)定 和 回調(diào)執(zhí)行間的間隔是105ms。

到這里我們再總結(jié)一下，整個異步IO的流程：

問題五、nodejs擅長什么？不擅長什么？

Node.js 通過 libuv 來處理與操作系統(tǒng)的交互，并且因此具備了異步、非阻塞、事件驅(qū)動的能力。因此，NodeJS能響應(yīng)大量的并發(fā)請求。所以，NodeJS適合運用在高并發(fā)、I/O密集、少量業(yè)務(wù)邏輯的場景。

上面提到，如果是 I/O 任務(wù)，Node.js 就把任務(wù)交給線程池來異步處理，高效簡單，因此 Node.js 適合處理I/O密集型任務(wù)。但不是所有的任務(wù)都是 I/O 密集型任務(wù)，當碰到CPU密集型任務(wù)時，即只用CPU計算的操作，比如要對數(shù)據(jù)加解密(node.bcrypt.js)，數(shù)據(jù)壓縮和解壓(node-tar)，這時 Node.js 就會親自處理，一個一個的計算，前面的任務(wù)沒有執(zhí)行完，后面的任務(wù)就只能干等著 。我們看如下代碼：

var start = Date.now();//獲取當前時間戳

setTimeout(function () {

console.log(Date.now() - start);

for (var i = 0; i < 1000000000; i++){//執(zhí)行長循環(huán)

}

}, 1000);

setTimeout(function () {

console.log(Date.now() - start);

}, 2000);

最終我們的打印結(jié)果是：(結(jié)果可能因為你的機器而不同)

1000

3738

對于我們期望2秒后執(zhí)行的setTimeout函數(shù)其實經(jīng)過了3738毫秒之后才執(zhí)行，換而言之，因為執(zhí)行了一個很長的for循環(huán)，所以我們整個Node.js主線程被阻塞了，如果在我們處理100個用戶請求中，其中第一個有需要這樣大量的計算，那么其余99個就都會被延遲執(zhí)行。如果操作系統(tǒng)本身就是單核，那也就算了，但現(xiàn)在大部分服務(wù)器都是多 CPU 或多核的，而 Node.js 只有一個 EventLoop，也就是只占用一個 CPU 內(nèi)核，當 Node.js 被CPU 密集型任務(wù)占用，導致其他任務(wù)被阻塞時，卻還有 CPU 內(nèi)核處于閑置狀態(tài)，造成資源浪費。

其實雖然Node.js可以處理數(shù)以千記的并發(fā)，但是一個Node.js進程在某一時刻其實只是在處理一個請求。

因此，Node.js 并不適合 CPU 密集型任務(wù)。

總結(jié)

以上是生活随笔為你收集整理的为什么nodejs是单进程的_nodejs真的是单线程吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。