Node.js中的單線程模型是什么

這期內容當中小編將會給大家帶來有關Node.js中的單線程模型是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

1、高并發

一般來說，高并發的解決方案就是多線程模型，服務器為每個客戶端請求分配一個線程，使用同步I/O，系統通過線程切換來彌補同步I/O調用的時間開銷，比如Apache就是這種策略，由于I/O一般都是耗時操作，因此這種策略很難實現高性能，但非常簡單，可以實現復雜的交互邏輯。

而事實上，大多數網站的服務器端都不會做太多的計算，它們只是接收請求，交給其它服務（比如從數據庫讀取數據），然后等著結果返回再發給客戶端。因此，Node.js針對這一事實采用了單線程模型來處理，它不會為每個接入請求分配一個線程，而是用一個主線程處理所有的請求，然后對I/O操作進行異步處理，避開了創建、銷毀線程以及在線程間切換所需的開銷和復雜性。

2、事件循環

Node.js 在主線程中維護了一個事件隊列，當接收到請求后，就將請求作為一個事件放入該隊列中，然后繼續接收其他請求。當主線程空閑時(沒有請求接入時)，就開始循環事件隊列，檢查隊列中是否有要處理的事件，這時要分兩種情況：如果是非I/O任務，就親自處理，并通過回調函數返回到上層調用；如果是I/O任務，就從線程池中拿出一個線程來執行這個事件，并指定回調函數，然后繼續循環隊列中的其他事件。當線程中的I/O任務完成后，就執行指定的回調函數，并把這個完成的事件放到事件隊列的尾部，等待事件循環，當主線程再次循環到該事件時，就直接處理并返回給上層調用。 這個過程就叫事件循環(Event Loop)，如下圖所示：

這個圖是整個Node.js的運行原理，從左到右，從上到下，Node.js被分成了四層，分別是應用層、V8引擎層、Node API層 和 LIBUV層，

應用層：   即Javascript交互層，常見的就是Node.js的模塊，比如 http，fs
V8引擎層：  即利用V8引擎來解析Javascript語法，進而和下層API交互
NodeAPI層：  為上層模塊提供系統調用，一般是由C語言來實現，和操作系統進行交互
LIBUV層： 即Event Loop，是Node.js實現異步的核心，由LIBUV庫來實現，而LIBUV中的線程池是由操作系統內核接受管理的。

從上述理解來看，Node.js的單線程僅僅是指Javascript運行在單線程中，而并非Node.js是單線程，在Node中，無論是Linux平臺還是Windows平臺，內部都是通過線程池來完成IO操作，而LIBUV就是針對不同平臺的差異性實現了統一調用。

3、事件驅動

總結上面的過程可以發現，Node.js的核心是使用事件驅動模式實現了異步I/O，為了更具體、更清晰的理解和接受這個事實，我們用代碼來描述Node.js的事件驅動模型：

3.1、事件隊列

首先，我們需要定義一個事件隊列，既然是隊列，那就是一個先進先出(FIFO)的數據結構，我們用JS的數組來描述，如下：

/**
 * 定義事件隊列
 * 入隊：unshfit()
 * 出隊：pop()
 * 空隊列：length == 0
 */
eventQueue:[],

為了方便理解，我們規定：數組的第一個元素是隊列的尾部，數組的最后一個元素是隊列的頭部， unshfit 就是在尾部插入一個元素，pop就是從頭部彈出一個元素，這樣就實現了一個簡單的隊列。

3.2、接收請求

定義一個總的入口來接收用戶請求，如下所示：

/**
 * 接收用戶請求
 * 每一個請求都會進入到該函數
 * 傳遞參數request和response
 */
processHttpRequest:function(request,response){
   
  //定義一個事件對象
  var event = createEvent({
    params:request.params, //傳遞請求參數
    result:null, //存放請求結果
    callback:function(){} //指定回調函數
  });
 
  //在隊列的尾部添加該事件 
  eventQueue.unshift(event);
},

這個函數很簡單，就是把用戶的請求包裝成事件，放到隊列里，然后繼續接收其他請求。

3.3、事件循環

當主線程處于空閑時就開始循環事件隊列，所以，我們再定義一個事件循環的函數：

/**
 * 事件循環主體，主線程擇機執行
 * 循環遍歷事件隊列
 * 處理事件
 * 執行回調，返回給上層
 */
eventLoop:function(){
  //如果隊列不為空，就繼續循環
  while(this.eventQueue.length > 0){
    //從隊列的頭部拿出一個事件
    var event = this.eventQueue.pop();
    //如果是IO任務
    if(isIOTask(event)){
      //從線程池里拿出一個線程
      var thread = getThreadFromThreadPool();
      //交給線程處理
      thread.handleIOTask(event)
    }else {
      //非IO任務處理后，直接返回結果
      var result = handleEvent(event);
      //最終通過回調函數返回給V8，再由V8返回給應用程序
      event.callback.call(null,result);
    }
  }
},

主線程不停的檢測事件隊列，對于IO任務就交給線程池來處理，非IO任務就自己處理并返回。

3.4、線程池

線程池接到任務以后，直接處理IO操作，比如讀取數據庫：

當IO

/**
 * 處理IO任務
 * 完成后將事件添加到隊列尾部
 * 釋放線程
 */
handleIOTask:function(event){
  //當前線程
  var curThread = this;
 
  //操作數據庫
  var optDatabase = function(params,callback){
    var result = readDataFromDb(params);
    callback.call(null,result)
  };
   
  //執行IO任務
  optDatabase(event.params,function(result){
    //返回結果存入事件對象中
    event.result = result;
 
    //IO完成后，將不再是耗時任務
    event.isIOTask = false;
     
    //將該事件重新添加到隊列的尾部
    this.eventQueue.unshift(event);
     
    //釋放當前線程
    releaseThread(curThread)
  })
}

任務完成以后就執行回調，把請求結果存入事件中，并將該事件重新放入隊列中，等待循環，最后釋放線程。當主線程再次循環到該事件時，就直接處理了。

 4、Node.js軟肋

以上四步簡單描述了Node.js事件驅動模型，至此，我們對Node.js應該有了一個簡單而又清晰的認識，但Node.js 并不是什么都能做。

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

在事件隊列中，如果前面的CPU計算任務沒有完成，那么后面的任務就會被阻塞，出現響應緩慢的情況，如果操作系統本身就是單核，那也就算了，但現在大部分服務器都是多CPU或多核的，而Node.js只有一個EventLoop，也只占用一個CPU/內核，當Node.js被CPU密集型任務占用，導致其他任務被阻塞時，卻還有CPU/內核處理閑置狀態，造成資源浪費。因此Node.js不適合CPU密集型任務。

5、Node.js適用場景

5.1、RESTful API

這是適合 Node 的理想情況，因為您可以構建它來處理數萬條連接。它仍然不需要大量邏輯；它本質上只是從某個數據庫中查找一些值并將它們組成一個響應。由于響應是少量文本，入站請求也是少量的文本，因此流量不高，一臺機器甚至也可以處理最繁忙的公司的 API 需求。

5.2、實時程序

比如聊天服務，聊天應用程序是最能體現 Node.js 優點的例子：輕量級、高流量并且能良好的應對跨平臺設備上運行密集型數據（雖然計算能力低）。同時，聊天也是一個非常值得學習的用例，因為它很簡單，并且涵蓋了目前為止一個典型的 Node.js 會用到的大部分解決方案。

上述就是小編為大家分享的Node.js中的單線程模型是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。