前言

從Node.js進(jìn)入我們的視野時(shí)，我們所知道的它就由這些關(guān)鍵字組成 事件驅(qū)動(dòng)、非阻塞I/O、高效、輕量，它在官網(wǎng)中也是這么描述自己的。
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.

于是在我們剛接觸Nodejs時(shí)，會(huì)有所疑問(wèn)：

1、為什么在瀏覽器中運(yùn)行的Javascript能與操作系統(tǒng)進(jìn)行如此底層的交互？ 
2、nodejs 真的是單線程嗎？
3、如果是單線程，他是如何處理高并發(fā)請(qǐng)求的？
4、nodejs 事件驅(qū)動(dòng)是如何實(shí)現(xiàn)的？

看到這些問(wèn)題，是否有點(diǎn)頭大，別急，帶著這些問(wèn)題我們來(lái)慢慢看這篇文章。

架構(gòu)一覽

上面的問(wèn)題，都挺底層的，所以我們從 Node.js 本身入手，先來(lái)看看 Node.js 的結(jié)構(gòu)。 

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

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

這一層是支撐 Node.js 運(yùn)行的關(guān)鍵，由 C/C++ 實(shí)現(xiàn)。
V8：Google 推出的 Javascript VM，也是 Node.js 為什么使用的是 Javascript的關(guān)鍵，它為 Javascript提供了在非瀏覽器端運(yùn)行的環(huán)境，它的高效是 Node.js 之所以高效的原因之一。
Libuv：它為 Node.js 提供了跨平臺(tái)，線程池，事件池，異步 I/O 等能力，是 Node.js 如此強(qiáng)大的關(guān)鍵。
C-ares：提供了異步處理 DNS 相關(guān)的能力。
http_parser、OpenSSL、zlib 等：提供包括 http 解析、SSL、數(shù)據(jù)壓縮等其他的能力。

與操作系統(tǒng)交互

舉個(gè)簡(jiǎn)單的例子，我們想要打開(kāi)一個(gè)文件，并進(jìn)行一些操作，可以寫下面這樣一段代碼：

var fs = require('fs');fs.open('./test.txt', "w", function(err, fd) {    //..do something});

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

lib/fs.js

async function open(path, flags, mode) {  mode = modeNum(mode, 0o666);  path = getPathFromURL(path);
  validatePath(path);
  validateUint32(mode, 'mode');
  return new FileHandle(
    await binding.openFileHandle(pathModule.toNamespacedPath(path),
             stringToFlags(flags),             mode, kUsePromises));
}

src/node_file.cc

static void Open(const FunctionCallbackInfo& args) {  Environment* env = Environment::GetCurrent(args);  const int argc = args.Length();  if (req_wrap_async != nullptr) {  // open(path, flags, mode, req)    AsyncCall(env, req_wrap_async, args, "open", UTF8, AfterInteger,
              uv_fs_open, *path, flags, mode);
  } else {  // open(path, flags, mode, undefined, ctx)    CHECK_EQ(argc, 5);    FSReqWrapSync req_wrap_sync;    FS_SYNC_TRACE_BEGIN(open);    int result = SyncCall(env, args[4], &req_wrap_sync, "open",
                          uv_fs_open, *path, flags, mode);    FS_SYNC_TRACE_END(open);
    args.GetReturnValue().Set(result);
  }
}

uv_fs

/* Open the destination file. */
  dstfd = uv_fs_open(NULL,                     &fs_req,
                     req->new_path,
                     dst_flags,
                     statsbuf.st_mode,                     NULL);
  uv_fs_req_cleanup(&fs_req);

Node.js 深入淺出上的一幅圖：

具體來(lái)說(shuō)，當(dāng)我們調(diào)用 fs.open 時(shí)，Node.js 通過(guò) process.binding 調(diào)用 C/C++ 層面的 Open 函數(shù)，然后通過(guò)它調(diào)用 Libuv 中的具體方法 uv_fs_open，最后執(zhí)行的結(jié)果通過(guò)回調(diào)的方式傳回，完成流程。

我們?cè)?Javascript中調(diào)用的方法，最終都會(huì)通過(guò) process.binding 傳遞到 C/C++ 層面，最終由他們來(lái)執(zhí)行真正的操作。Node.js 即這樣與操作系統(tǒng)進(jìn)行互動(dòng)。

單線程

在傳統(tǒng)web 服務(wù)模型中，大多都使用多線程來(lái)解決并發(fā)的問(wèn)題，因?yàn)镮/O 是阻塞的，單線程就意味著用戶要等待，顯然這是不合理的，所以創(chuàng)建多個(gè)線程來(lái)響應(yīng)用戶的請(qǐng)求。
Node.js 對(duì)http 服務(wù)的模型：

Node.js的單線程指的是主線程是“單線程”，由主要線程去按照編碼順序一步步執(zhí)行程序代碼，假如遇到同步代碼阻塞，主線程被占用，后續(xù)的程序代碼執(zhí)行就會(huì)被卡住。實(shí)踐一個(gè)測(cè)試代碼：

var http = require('http');function sleep(time) {    var _exit = Date.now() + time * 1000;    while( Date.now() < _exit ) {}    return ;
}var server = http.createServer(function(req, res){
    sleep(10);
    res.end('server sleep 10s');
});

server.listen(8080);

下面為代碼塊的堆棧圖： 

先將index.js的代碼改成這樣，然后打開(kāi)瀏覽器，你會(huì)發(fā)現(xiàn)瀏覽器在10秒之后才做出反應(yīng)，打出Hello Node.js。

JavaScript是解析性語(yǔ)言，代碼按照編碼順序一行一行被壓進(jìn)stack里面執(zhí)行，執(zhí)行完成后移除然后繼續(xù)壓下一行代碼塊進(jìn)去執(zhí)行。上面代碼塊的堆棧圖，當(dāng)主線程接受了request后，程序被壓進(jìn)同步執(zhí)行的sleep執(zhí)行塊（我們假設(shè)這里就是程序的業(yè)務(wù)處理），如果在這10s內(nèi)有第二個(gè)request進(jìn)來(lái)就會(huì)被壓進(jìn)stack里面等待10s執(zhí)行完成后再進(jìn)一步處理下一個(gè)請(qǐng)求，后面的請(qǐng)求都會(huì)被掛起等待前面的同步執(zhí)行完成后再執(zhí)行。

那么我們會(huì)疑問(wèn)：為什么一個(gè)單線程的效率可以這么高，同時(shí)處理數(shù)萬(wàn)級(jí)的并發(fā)而不會(huì)造成阻塞呢？就是我們下面所說(shuō)的--------事件驅(qū)動(dòng)。

事件驅(qū)動(dòng)/事件循環(huán)

Event Loop is a programming construct that waits for and dispatches events or messages in a program. 

1、每個(gè)Node.js進(jìn)程只有一個(gè)主線程在執(zhí)行程序代碼，形成一個(gè)執(zhí)行棧（execution context stack)。
2、主線程之外，還維護(hù)了一個(gè)"事件隊(duì)列"（Event queue）。當(dāng)用戶的網(wǎng)絡(luò)請(qǐng)求或者其它的異步操作到來(lái)時(shí)，node都會(huì)把它放到Event Queue之中，此時(shí)并不會(huì)立即執(zhí)行它，代碼也不會(huì)被阻塞，繼續(xù)往下走，直到主線程代碼執(zhí)行完畢。
3、主線程代碼執(zhí)行完畢完成后，然后通過(guò)Event Loop，也就是事件循環(huán)機(jī)制，開(kāi)始到Event Queue的開(kāi)頭取出第一個(gè)事件，從線程池中分配一個(gè)線程去執(zhí)行這個(gè)事件，接下來(lái)繼續(xù)取出第二個(gè)事件，再?gòu)木€程池中分配一個(gè)線程去執(zhí)行，然后第三個(gè)，第四個(gè)。主線程不斷的檢查事件隊(duì)列中是否有未執(zhí)行的事件，直到事件隊(duì)列中所有事件都執(zhí)行完了，此后每當(dāng)有新的事件加入到事件隊(duì)列中，都會(huì)通知主線程按順序取出交EventLoop處理。當(dāng)有事件執(zhí)行完畢后，會(huì)通知主線程，主線程執(zhí)行回調(diào)，線程歸還給線程池。
4、主線程不斷重復(fù)上面的第三步。

我們所看到的node.js單線程只是一個(gè)js主線程，本質(zhì)上的異步操作還是由線程池完成的，node將所有的阻塞操作都交給了內(nèi)部的線程池去實(shí)現(xiàn)，本身只負(fù)責(zé)不斷的往返調(diào)度，并沒(méi)有進(jìn)行真正的I/O操作，從而實(shí)現(xiàn)異步非阻塞I/O，這便是node單線程和事件驅(qū)動(dòng)的精髓之處了。

Node.js 中的事件循環(huán)**的實(shí)現(xiàn)：**

Node.js采用V8作為js的解析引擎，而I/O處理方面使用了自己設(shè)計(jì)的libuv，libuv是一個(gè)基于事件驅(qū)動(dòng)的跨平臺(tái)抽象層，封裝了不同操作系統(tǒng)一些底層特性，對(duì)外提供統(tǒng)一的API，事件循環(huán)機(jī)制也是它里面的實(shí)現(xiàn)。 在src/node.cc中：

Environment* CreateEnvironment(IsolateData* isolate_data,
                               Local context,                               int argc,                               const char* const* argv,                               int exec_argc,                               const char* const* exec_argv) {
  Isolate* isolate = context->GetIsolate();  HandleScope handle_scope(isolate);
  Context::Scope context_scope(context);  auto env = new Environment(isolate_data, context,
                             v8_platform.GetTracingAgent());
  env->Start(argc, argv, exec_argc, exec_argv, v8_is_profiling);  return env;
}

這段代碼建立了一個(gè)node執(zhí)行環(huán)境，可以看到第三行的uv_default_loop()，這是libuv庫(kù)中的一個(gè)函數(shù)，它會(huì)初始化uv庫(kù)本身以及其中的default_loop_struct，并返回一個(gè)指向它的指針default_loop_ptr。 之后，Node會(huì)載入執(zhí)行環(huán)境并完成一些設(shè)置操作，然后啟動(dòng)event loop

{
    SealHandleScope seal(isolate);
    bool more;
    env.performance_state()->Mark(
        node::performance::NODE_PERFORMANCE_MILESTONE_LOOP_START);
    do {
      uv_run(env.event_loop(), UV_RUN_DEFAULT);

      v8_platform.DrainVMTasks(isolate);

      more = uv_loop_alive(env.event_loop());      if (more)
        continue;

      RunBeforeExit(&env);      // Emit `beforeExit` if the loop became alive either after emitting
      // event, or after running some callbacks.
      more = uv_loop_alive(env.event_loop());
    } while (more == true);
    env.performance_state()->Mark(
        node::performance::NODE_PERFORMANCE_MILESTONE_LOOP_EXIT);
  }

  env.set_trace_sync_io(false);

  const int exit_code = EmitExit(&env);
  RunAtExit(&env);

more用來(lái)標(biāo)識(shí)是否進(jìn)行下一輪循環(huán)。 env->event_loop()會(huì)返回之前保存在env中的default_loop_ptr，uv_run函數(shù)將以指定的UV_RUN_DEFAULT模式啟動(dòng)libuv的event loop。如果當(dāng)前沒(méi)有I/O事件也沒(méi)有定時(shí)器事件，則uv_loop_alive返回false。

Event Loop的執(zhí)行順序

根據(jù)Node.js官方介紹，每次事件循環(huán)都包含了6個(gè)階段，對(duì)應(yīng)到 libuv 源碼中的實(shí)現(xiàn)，如下圖所示： 

• timers 階段：這個(gè)階段執(zhí)行timer（setTimeout、setInterval）的回調(diào)
• I/O callbacks 階段：執(zhí)行一些系統(tǒng)調(diào)用錯(cuò)誤，比如網(wǎng)絡(luò)通信的錯(cuò)誤回調(diào)
• idle, prepare 階段：僅node內(nèi)部使用
• poll 階段：獲取新的I/O事件, 適當(dāng)?shù)臈l件下node將阻塞在這里
• check 階段：執(zhí)行setImmediate()的回調(diào)
• close callbacks 階段：執(zhí)行socket的close事件回調(diào)。

核心函數(shù)uv_run：源碼 核心源碼

int uv_run(uv_loop_t* loop, uv_run_mode mode) {  int timeout;  int r;  int ran_pending;//首先檢查我們的loop還是否活著//活著的意思代表loop中是否有異步任務(wù)//如果沒(méi)有直接就結(jié)束
  r = uv__loop_alive(loop);  if (!r)
    uv__update_time(loop);//傳說(shuō)中的事件循環(huán)，你沒(méi)看錯(cuò)了??！就是一個(gè)大while
  while (r != 0 && loop->stop_flag == 0) { //更新事件階段
    uv__update_time(loop); //處理timer回調(diào)
    uv__run_timers(loop); //處理異步任務(wù)回調(diào) 
    ran_pending = uv__run_pending(loop);//沒(méi)什么用的階段
    uv__run_idle(loop);
    uv__run_prepare(loop);    //這里值得注意了
    //從這里到后面的uv__io_poll都是非常的不好懂的
    //先記住timeout是一個(gè)時(shí)間
    //uv_backend_timeout計(jì)算完畢后，傳遞給uv__io_poll
    //如果timeout = 0,則uv__io_poll會(huì)直接跳過(guò)
    timeout = 0;    if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT)
      timeout = uv_backend_timeout(loop);

    uv__io_poll(loop, timeout);    //就是跑setImmediate
    uv__run_check(loop);    //關(guān)閉文件描述符等操作
    uv__run_closing_handles(loop);    if (mode == UV_RUN_ONCE) {      /* UV_RUN_ONCE implies forward progress: at least one callback must have
       * been invoked when it returns. uv__io_poll() can return without doing
       * I/O (meaning: no callbacks) when its timeout expires - which means we
       * have pending timers that satisfy the forward progress constraint.
       *
       * UV_RUN_NOWAIT makes no guarantees about progress so it's omitted from
       * the check.
       */
      uv__update_time(loop);
      uv__run_timers(loop);
    }

    r = uv__loop_alive(loop);    if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)      break;
  }  /* The if statement lets gcc compile it to a conditional store. Avoids
   * dirtying a cache line.
   */
  if (loop->stop_flag != 0)    loop->stop_flag = 0;  return r;
}

代碼中我已經(jīng)寫得很詳細(xì)了，相信不熟悉c代碼的各位也能輕易搞懂，沒(méi)錯(cuò)，事件循環(huán)就是一個(gè)大while而已！神秘的面紗就此揭開(kāi)。

uv__io_poll階段

這個(gè)階段設(shè)計(jì)得非常巧妙，這個(gè)函數(shù)第二個(gè)參數(shù)是一個(gè)timeout參數(shù)，而這個(gè)timeOut由來(lái)自u(píng)v_backend_timeout函數(shù)，我們進(jìn)去一探究竟！

源碼

int uv_backend_timeout(const uv_loop_t* loop) {  if (loop->stop_flag != 0)    return 0;  if (!uv__has_active_handles(loop) && !uv__has_active_reqs(loop))    return 0;  if (!QUEUE_EMPTY(&loop->idle_handles))    return 0;  if (!QUEUE_EMPTY(&loop->pending_queue))    return 0;  if (loop->closing_handles)    return 0;  return uv__next_timeout(loop);
}

原來(lái)是一個(gè)多步if函數(shù)，我們一個(gè)一個(gè)分析

1. stop_flag:這個(gè)標(biāo)記是 0的時(shí)候，意味著事件循環(huán)跑完這一輪就退出了，返回的時(shí)間是0

2. !uv__has_active_handles和!uv__has_active_reqs:看名字都知道，如果沒(méi)有任何的異步任務(wù)（包括timer和異步I/O)，那timeOut時(shí)間一定就是0了

3. QUEUE_EMPTY(idle_handles)和QUEUE_EMPTY(pending_queue):異步任務(wù)是通過(guò)注冊(cè)的方式放進(jìn)了pending_queue中，無(wú)論是否成功，都已經(jīng)被注冊(cè)，如果什么都沒(méi)有，這兩個(gè)隊(duì)列就是空，所以沒(méi)必要等了。

4. closing_handles:我們的循環(huán)進(jìn)入了關(guān)閉階段，沒(méi)必要等待了

以上所有條件判斷來(lái)判斷去，為的就是等這句話return uv__next_timeout(loop);這句話，告訴了uv__io_poll說(shuō)：你到底停多久，接下來(lái)，我們繼續(xù)看這個(gè)神奇的uv__next_timeout是怎么獲取時(shí)間的。

int uv__next_timeout(const uv_loop_t* loop) {  const struct heap_node* heap_node;  const uv_timer_t* handle;
  uint64_t diff;

  heap_node = heap_min((const struct heap*) &loop->timer_heap);  if (heap_node == NULL)    return -1; /* block indefinitely */

  handle = container_of(heap_node, uv_timer_t, heap_node);  if (handle->timeout time)    return 0;//這句代碼給出了關(guān)鍵性的指導(dǎo)
  diff = handle->timeout - loop->time;//不能大于最大的INT_MAX
  if (diff > INT_MAX)
    diff = INT_MAX;  return diff;
}

等待結(jié)束以后，就會(huì)進(jìn)入check 階段.然后進(jìn)入closing_handles階段，至此一個(gè)事件循環(huán)結(jié)束。 因?yàn)槭窃创a解析，所以具體的我就不多說(shuō)，大家只可以看官方文檔

總結(jié)

1、Nodejs與操作系統(tǒng)交互，我們?cè)?Javascript中調(diào)用的方法，最終都會(huì)通過(guò) process.binding 傳遞到 C/C++ 層面，最終由他們來(lái)執(zhí)行真正的操作。Node.js 即這樣與操作系統(tǒng)進(jìn)行互動(dòng)。

2、nodejs所謂的單線程，只是主線程是單線程，所有的網(wǎng)絡(luò)請(qǐng)求或者異步任務(wù)都交給了內(nèi)部的線程池去實(shí)現(xiàn)，本身只負(fù)責(zé)不斷的往返調(diào)度，由事件循環(huán)不斷驅(qū)動(dòng)事件執(zhí)行。

3、Nodejs之所以單線程可以處理高并發(fā)的原因，得益于libuv層的事件循環(huán)機(jī)制，和底層線程池實(shí)現(xiàn)。

4、Event loop就是主線程從主線程的事件隊(duì)列里面不停循環(huán)的讀取事件，驅(qū)動(dòng)了所有的異步回調(diào)函數(shù)的執(zhí)行，Event loop總共7個(gè)階段，每個(gè)階段都有一個(gè)任務(wù)隊(duì)列，當(dāng)所有階段被順序執(zhí)行一次后，event loop 完成了一個(gè) tick。

以上就是Nodejs探秘之深入理解單線程實(shí)現(xiàn)高并發(fā)原理的詳細(xì)內(nèi)容，更多關(guān)于Nodejs的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論