Node.js中線程和進程的詳細分析

這篇文章帶給大家的內容是關於Node.js中線程和進程的詳細分析，有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。

早期有很多關於Node.js爭論的焦點都在它的單線程模型方面，在由Jani Hartikainen寫的一篇著名的文章《PHP優於Node.js的五大理由》中，更有一條矛頭直接指向Node.js單線程脆弱的問題。

如果PHP程式碼損壞，不會拖垮整個伺服器。 PHP程式碼只運行在自己的進程範圍中，當某個請求顯示錯誤時，它只會對特定的請求產生影響。而在Node.js環境中，所有的請求都在單一的進程服務中，當某個請求導致未知錯誤時，整個伺服器都會受到影響。

　　Node.js和Apache PHP還有一個非常不同的地方就是進程的運行時間長短，當然這一點也被此文作為一個PHP優於Node.js的理由來寫了。

PHP進程短暫。在PHP中，每個進程對請求持續的時間很短暫，這意味著你不必為資源配置和記憶體而擔憂。而Node.js的進程需要運行很長一段時間，你需要小心並妥善管理好記憶體。例如，如果你忘記從全域資料中刪除條目，這會輕易的導致記憶體外洩。

　　在這裡我們並不想引起一次關於PHP和Node.js孰優孰劣的口水仗，PHP和Node.js各代表著一個互聯網時代的開發語言，就如同我們討論跑車和越野車誰比較好一樣，它們都有自己擅長和適用的場景。我們可以透過下面這兩張圖來深入理解PHP和Node.js對處理Http請求時的差異。

　　PHP的模型：

#　　Node.js的模型：

#　　所以你在寫Node.js程式碼時，要保持清醒的頭腦，任何一個隱藏著的異常被觸發後，都會將整個Node.js進程擊潰。但這樣的特性也為我們寫程式碼帶來便利，例如同樣要實作一個簡單的網站存取次數統計，Node.js只需要在記憶體裡定義一個變數var count=0;，每次有使用者請求過來執行count ;即可。

var http = require('http');
var count = 0;
http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end((++count).toString())
}).listen(8124);
console.log('Server running at http://127.0.0.1:8124/');

　　但是對於PHP來說就需要使用第三方媒介來儲存這個count值了，例如建立一個count.txt檔案來保存網站的造訪次數。

$counter_file = ("count.txt");
    $visits = file($counter_file);
    $visits[0]++;
    $fp = fopen($counter_file,"w");
    fputs($fp,"$visits[0]");
    fclose($fp);
    echo "$visits[0]";
?>

　單線程的js

　　Google的V8 Javascript引擎已經在Chrome瀏覽器裡證明了它的效能，所以Node.js的作者Ryan Dahl選擇了v8作為Node.js的執行引擎，v8賦予Node.js高效能的同時也注定了Node.js和大名鼎鼎的Nginx一樣，都是以單線程為基礎的，當然這也正是作者Ryan Dahl設計Node.js的初衷。

　單線程的優缺點

　　Node.js的單線程具有它的優勢，但也並非十全十美，在保持單線程模型的同時，它是如何保證非阻塞的呢？

　　高效能

　　首先，單執行緒避免了傳統PHP那樣頻繁地建立、切換執行緒的開銷，使執行速度更加迅速。第二，資源佔用小，如果有對Node.js的web伺服器做過壓力測試的朋友可能發現，Node.js在大負荷下對內存佔用仍然很低，同樣的負載PHP因為一個請求一個線程的模型，將會佔用大量的實體內存，很可能會導致伺服器因實體記憶體耗盡而頻繁交換，失去回應。

　　執行緒安全性

　　單執行緒的js也保證了絕對的執行緒安全，不用擔心同一變數同時被多個執行緒進行讀寫而造成的程式崩潰。例如我們之前做的web訪問統計，因為單線程的絕對線程安全，所以不可能存在同時對count變量進行讀寫的情況，我們的統計代碼就算是成百的並髮用戶請求都不會出現問題，相較PHP的那種存檔案記錄訪問，就會面臨並發同時寫文件的問題。線程安全的同時也解放了開發人員，免去了多線程編程中忘記對變量加鎖或解鎖造成的悲劇。

　　單線程的非同步和非阻塞

　　Node.js是單線程的，但是它如何做到I/O的非同步和非阻塞的呢？其實Node.js在底層存取I/O還是多執行緒的，有興趣的朋友可以翻看Node.js的fs模組的源碼，裡面會用到libuv來處理I/O，所以在我們看來Node.js的程式碼就是非阻塞和非同步形式的。

　　阻塞/非阻塞與非同步/同步是兩個不同的概念，同步不代表阻塞，但是阻塞肯定就是同步了。

　　举个现实生活中的例子，我去食堂打饭，我选择了A套餐，然后工作人员帮我去配餐，如果我就站在旁边，等待工作人员给我配餐，这种情况就称之为同步；若工作人员帮我配餐的同时，排在我后面的人就开始点餐，这样整个食堂的点餐服务并没有因为我在等待A套餐而停止，这种情况就称之为非阻塞。这个例子就简单说明了同步但非阻塞的情况。

　　再如果我在等待配餐的时候去买饮料，等听到叫号再回去拿套餐，此时我的饮料也已经买好，这样我在等待配餐的同时还执行了买饮料的任务，叫号就等于执行了回调，就是异步非阻塞了。

　　阻塞的单线程

　　既然Node.js是单线程异步非阻塞的，是不是我们就可以高枕无忧了呢？

　　还是拿上面那个买套餐的例子，如果我在买饮料的时候，已经叫我的号让我去拿套餐，可是我等了好久才拿到饮料，所以我可能在大厅叫我的餐号之后很久才拿到A套餐，这也就是单线程的阻塞情况。

　　在浏览器中，js都是以单线程的方式运行的，所以我们不用担心js同时执行带来的冲突问题，这对于我们编码带来很多的便利。

　　但是对于在服务端执行的Node.js，它可能每秒有上百个请求需要处理，对于在浏览器端工作良好的单线程js是否也能同样在服务端表现良好呢？

　　我们看如下代码：

var start = Date.now();//获取当前时间戳
setTimeout(function () {
    console.log(Date.now() - start);
    for (var i = 0; i < 1000000000; i++){//执行长循环
    }
}, 1000);
setTimeout(function () {
    console.log(Date.now() - start);
}, 2000);

　　最终我们的打印结果是：（结果可能因为你的机器而不同）

1000

3738

　　对于我们期望2秒后执行的setTimeout函数其实经过了3738毫秒之后才执行，换而言之，因为执行了一个很长的for循环，所以我们整个Node.js主线程被阻塞了，如果在我们处理100个用户请求中，其中第一个有需要这样大量的计算，那么其余99个就都会被延迟执行。

　　其实虽然Node.js可以处理数以千记的并发，但是一个Node.js进程在某一时刻其实只是在处理一个请求。

　　单线程和多核

　　线程是cpu调度的一个基本单位，一个cpu同时只能执行一个线程的任务，同样一个线程任务也只能在一个cpu上执行，所以如果你运行Node.js的机器是像i5，i7这样多核cpu，那么将无法充分利用多核cpu的性能来为Node.js服务。

　多线程

　　在C++、C#、python等其他语言都有与之对应的多线程编程，有些时候这很有趣，带给我们灵活的编程方式；但是也可能带给我们一堆麻烦，需要学习更多的Api知识，在编写更多代码的同时也存在着更多的风险，线程的切换和锁也会造成系统资源的开销。

　　就像上面的那个例子，如果我们的Node.js有创建子线程的能力，那问题就迎刃而解了：

var start = Date.now();
createThread(function () { //创建一个子线程执行这10亿次循环
    console.log(Date.now() - start);
    for (var i = 0; i < 1000000000; i++){}
});
setTimeout(function () { //因为10亿次循环是在子线程中执行的，所以主线程不受影响
    console.log(Date.now() - start);
}, 2000);

　　可惜也可以说可喜的是，Node.js的核心模块并没有提供这样的api给我们，我们真的不想多线程又回归回来。不过或许多线程真的能够解决我们某方面的问题。

　　tagg2模块

　　Jorge Chamorro Bieling是tagg(Threads a gogo for Node.js)包的作者，他硬是利用phread库和C语言让Node.js支持了多线程的开发，我们看一下tagg模块的简单示例：

var Threads = require('threads_a_gogo');//加载tagg包
function fibo(n) {//定义斐波那契数组计算函数
    return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}
var t = Threads.create().eval(fibo);
t.eval('fibo(35)', function(err, result) {//将fibo(35)丢入子线程运行
    if (err) throw err; //线程创建失败
    console.log('fibo(35)=' + result);//打印fibo执行35次的结果
});
console.log('not block');//打印信息了，表示没有阻塞

　　上面这段代码利用tagg包将fibo(35)这个计算丢入了子线程中进行，保证了Node.js主线程的舒畅，当子线程任务执行完毕将会执行主线程的回调函数，把结果打印到屏幕上，执行结果如下：

not block

fibo(35)=14930352

斐波那契数列，又称黄金分割数列，这个数列从第三项开始，每一项都等于前两项之和：0、1、1、2、3、5、8、13、21、……。

　　注意我们上面代码的斐波那契数组算法并不是最优算法，只是为了模拟cpu密集型计算任务。

　　由于tagg包目前只能在linux下安装运行，所以我fork了一个分支，修改了部分tagg包的代码，发布了tagg2包。tagg2包同样具有tagg包的多线程功能，采用新的node-gyp命令进行编译，同时它跨平台支持，mac，linux，windows下都可以使用，对开发人员的api也更加友好。安装方法很简单，直接npm install tagg2。

　　一个利用tagg2计算斐波那契数组的http服务器代码：

var express = require('express');
var tagg2 = require("tagg2");
var app = express();
var th_func = function(){//线程执行函数，以下内容会在线程中执行
    var fibo =function fibo (n) {//在子线程中定义fibo函数
          return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
        }
    var n = fibo(~~thread.buffer);//执行fibo递归
    thread.end(n);//当线程执行完毕，执行thread.end带上计算结果回调主线程
};
app.get('/', function(req, res){
    var n = ~~req.query.n || 1;//获取用户请求参数
    var buf = new Buffer(n.toString());
    tagg2.create(th_func, {buffer:buf}, function(err,result){
    //创建一个js线程,传入工作函数,buffer参数以及回调函数
        if(err) return res.end(err);//如果线程创建失败
        res.end(result.toString());//响应线程执行计算的结果
    })
});
app.listen(8124);
console.log('listen on 8124');

　　其中~~req.query.n表示将用户传递的参数n取整，功能类似Math.floor函数。

　　我们用express框架搭建了一个web服务器，根据用户发送的参数n的值来创建子线程计算斐波那契数组，当子线程计算完毕之后将结果响应给客户端。由于计算是丢入子线程中运行的，所以整个主线程不会被阻塞，还是能够继续处理新请求的。

我们利用apache的http压力测试工具ab来进行一次简单的压力测试，看看执行斐波那契数组35次，100客户端并发100个请求，我们的QPS (Query Per Second)每秒查询率在多少。

ab的全称是ApacheBench，是Apache附带的一个小工具，用于进行HTTP服务器的性能测试，可以同时模拟多个并发请求。

　　我们的测试硬件：linux 2.6.4 4cpu 8G 64bit，网络环境则是内网。

　　ab压力测试命令：

ab -c 100 -n 100 http://192.168.28.5:8124/?n=35

　　压力测试结果：

Server Software:       
Server Hostname:        192.168.28.5
Server Port:            8124
Document Path:          /?n=35
Document Length:        8 bytes
Concurrency Level:      100
Time taken for tests:  5.606 seconds
Complete requests:      100
Failed requests:        0
Write errors:          0
Total transferred:      10600 bytes
HTML transferred:      800 bytes
Requests per second:    17.84 [#/sec](mean)
Time per request:      5605.769 [ms](mean)
Time per request:      56.058 [ms](mean, across all concurrent requests)
Transfer rate:          1.85 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median  max
Connect:        3    4  0.8      4      6
Processing:  455 5367 599.7  5526    5598
Waiting:      454 5367 599.7  5526    5598
Total:        461 5372 599.3  5531    5602
Percentage of the requests served within a certain time (ms)
  50%  5531
  66%  5565
  75%  5577
  80%  5581
  90%  5592
  95%  5597
  98%  5600
  99%  5602
100%  5602 (longest request)

　　我们看到Requests per second表示每秒我们服务器处理的任务数量，这里是17.84。第二个我们比较关心的是两个Time per request结果，上面一行Time per request:5605.769 [ms](mean)表示当前这个并发量下处理每组请求的时间，而下面这个Time per request:56.058 [ms](mean, across all concurrent requests)表示每个用户平均处理时间，因为我们本次测试并发是100，所以结果正好是上一行的100分之1。得出本次测试平均每个用户请求的平均等待时间为56.058 [ms]。

　　另外我们看下最后带有百分比的列表，可以看到50%的用户是在5531 ms以内返回的，最慢的也不过5602 ms，响应延迟非常的平均。

　　我们如果用cluster来启动4个进程，是否可以充分利用cpu达到tagg2那样的QPS呢？我们在同样的网络环境和测试机上运行如下代码：

var cluster = require('cluster');//加载clustr模块
var numCPUs = require('os').cpus().length;//设定启动进程数为cpu个数
if (cluster.isMaster) {
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();//启动子进程
  }
} else {
    var express = require(&#39;express&#39;);
    var app = express();
    var fibo = function fibo (n) {//定义斐波那契数组算法
      return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
    }
    app.get(&#39;/&#39;, function(req, res){
      var n = fibo(~~req.query.n || 1);//接收参数
      res.send(n.toString());
    });
    app.listen(8124);
    console.log(&#39;listen on 8124&#39;);
}

　　在终端屏幕上打印了4行信息：

listen on 8124

listen on 8124

listen on 8124

listen on 8124

　　我们成功启动了4个cluster之后，用同样的ab压力测试命令对8124端口进行测试，结果如下：

Server Software:       
Server Hostname:        192.168.28.5
Server Port:            8124
Document Path:          /?n=35
Document Length:        8 bytes
Concurrency Level:      100
Time taken for tests:  10.509 seconds
Complete requests:      100
Failed requests:        0
Write errors:          0
Total transferred:      16500 bytes
HTML transferred:      800 bytes
Requests per second:    9.52 [#/sec](mean)
Time per request:      10508.755 [ms](mean)
Time per request:      105.088 [ms](mean, across all concurrent requests)
Transfer rate:          1.53 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median  max
Connect:        4    5  0.4      5      6
Processing:  336 3539 2639.8  2929  10499
Waiting:      335 3539 2639.9  2929  10499
Total:        340 3544 2640.0  2934  10504
Percentage of the requests served within a certain time (ms)
  50%  2934
  66%  3763
  75%  4527
  80%  5153
  90%  8261
  95%  9719
  98%  10308
  99%  10504
100%  10504 (longest request)

　　通过和上面tagg2包的测试结果对比，我们发现区别很大。首先每秒处理的任务数从17.84 [#/sec]下降到了9.52 [#/sec]，这说明我们web服务器整体的吞吐率下降了；然后每个用户请求的平均等待时间也从56.058 [ms]提高到了105.088 [ms]，用户等待的时间也更长了。

　　最后我们发现用户请求处理的时长非常的不均匀，50%的用户在2934 ms内返回了，最慢的等待达到了10504 ms。虽然我们使用了cluster启动了4个Node.js进程处理用户请求，但是对于每个Node.js进程来说还是单线程的，所以当有4个用户跑满了4个Node.js的cluster进程之后，新来的用户请求就只能等待了，最后造成了先到的用户处理时间短，后到的用户请求处理时间比较长，就造成了用户等待时间非常的不平均。

　　v8引擎

　　大家看到这里是不是开始心潮澎湃，感觉js一统江湖的时代来临了，单线程异步非阻塞的模型可以胜任大并发，同时开发也非常高效，多线程下的js可以承担cpu密集型任务，不会有主线程阻塞而引起的性能问题。

　　但是，不论tagg还是tagg2包都是利用phtread库和v8的v8::Isolate Class类来实现js多线程功能的。

Isolate代表着一个独立的v8引擎实例，v8的Isolate拥有完全分开的状态，在一个Isolate实例中的对象不能够在另外一个Isolate实例中使用。嵌入式开发者可以在其他线程创建一些额外的Isolate实例并行运行。在任何时刻，一个Isolate实例只能够被一个线程进行访问，可以利用加锁/解锁进行同步操作。

　　换而言之，我们在进行v8的嵌入式开发时，无法在多线程中访问js变量，这条规则将直接导致我们之前的tagg2里面线程执行的函数无法使用Node.js的核心api，比如fs，crypto等模块。如此看来，tagg2包还是有它使用的局限性，针对一些可以使用js原生的大量计算或循环可以使用tagg2，Node.js核心api因为无法从主线程共享对象的关系，也就不能跨线程使用了。

　　libuv

　　最后，如果我们非要让Node.js支持多线程，还是提倡使用官方的做法，利用libuv库来实现。

libuv是一个跨平台的异步I/O库，它主要用于Node.js的开发，同时他也被Mozilla's Rust language, Luvit, Julia, pyuv等使用。它主要包括了Event loops事件循环，Filesystem文件系统，Networking网络支持，Threads线程，Processes进程，Utilities其他工具。

　　在Node.js核心api中的异步多线程大多是使用libuv来实现的，下一章将带领大家开发一个让Node.js支持多线程并基于libuv的Node.js包。

　多进程

　　在支持html5的浏览器里，我们可以使用webworker来将一些耗时的计算丢入worker进程中执行，这样主进程就不会阻塞，用户也就不会有卡顿的感觉了。在Node.js中是否也可以使用这类技术，保证主线程的通畅呢？

　　cluster

　　cluster可以用来让Node.js充分利用多核cpu的性能，同时也可以让Node.js程序更加健壮，官网上的cluster示例已经告诉我们如何重新启动一个因为异常而奔溃的子进程。

　　webworker

　　想要像在浏览器端那样启动worker进程，我们需要利用Node.js核心api里的child_process模块。child_process模块提供了fork的方法，可以启动一个Node.js文件，将它作为worker进程，当worker进程工作完毕，把结果通过send方法传递给主进程，然后自动退出，这样我们就利用了多进程来解决主线程阻塞的问题。

　　我们先启动一个web服务，还是接收参数计算斐波那契数组：

var express = require('express');
var fork = require('child_process').fork;
var app = express();
app.get('/', function(req, res){
  var worker = fork('./work_fibo.js') //创建一个工作进程
  worker.on('message', function(m) {//接收工作进程计算结果
          if('object' === typeof m && m.type === 'fibo'){
                  worker.kill();//发送杀死进程的信号
                  res.send(m.result.toString());//将结果返回客户端
          }
  });
  worker.send({type:'fibo',num:~~req.query.n || 1});
  //发送给工作进程计算fibo的数量
});
app.listen(8124);

　　我们通过express监听8124端口，对每个用户的请求都会去fork一个子进程，通过调用worker.send方法将参数n传递给子进程，同时监听子进程发送消息的message事件，将结果响应给客户端。

　　下面是被fork的work_fibo.js文件内容：

var fibo = function fibo (n) {//定义算法
  return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}
process.on('message', function(m) {
//接收主进程发送过来的消息
          if(typeof m === 'object' && m.type === 'fibo'){
                  var num = fibo(~~m.num);
                  //计算jibo
                  process.send({type: 'fibo',result:num})
                  //计算完毕返回结果       
          }
});
process.on('SIGHUP', function() {
        process.exit();//收到kill信息，进程退出
});

　　我们先定义函数fibo用来计算斐波那契数组，然后监听了主线程发来的消息，计算完毕之后将结果send到主线程。同时还监听process的SIGHUP事件，触发此事件就进程退出。

　　这里我们有一点需要注意，主线程的kill方法并不是真的使子进程退出，而是会触发子进程的SIGHUP事件，真正的退出还是依靠process.exit();。

　　下面我们用ab 命令测试一下多进程方案的处理性能和用户请求延迟，测试环境不变，还是100个并发100次请求，计算斐波那切数组第35位:

Server Software:       
Server Hostname:        192.168.28.5
Server Port:            8124
Document Path:          /?n=35
Document Length:        8 bytes
Concurrency Level:      100
Time taken for tests:  7.036 seconds
Complete requests:      100
Failed requests:        0
Write errors:          0
Total transferred:      16500 bytes
HTML transferred:      800 bytes
Requests per second:    14.21 [#/sec](mean)
Time per request:      7035.775 [ms](mean)
Time per request:      70.358 [ms](mean, across all concurrent requests)
Transfer rate:          2.29 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median  max
Connect:        4    4  0.2      4      5
Processing:  4269 5855 970.3  6132    7027
Waiting:    4269 5855 970.3  6132    7027
Total:      4273 5860 970.3  6136    7032
Percentage of the requests served within a certain time (ms)
  50%  6136
  66%  6561
  75%  6781
  80%  6857
  90%  6968
  95%  7003
  98%  7017
  99%  7032
100%  7032 (longest request)

　　压力测试结果QPS约为14.21,相比cluster来说，还是快了很多，每个用户请求的延迟都很平均，因为进程的创建和销毁的开销要大于线程，所以在性能方面略低于tagg2，不过相对于cluster方案，这样的提升还是令我们满意的。

　　换一种思路

　　使用child_process模块的fork方法确实可以让我们很好的解决单线程对cpu密集型任务的阻塞问题，同时又没有tagg2包那样无法使用Node.js核心api的限制。

　　但是如果我的worker具有多样性，每次在利用child_process模块解决问题时都需要去创建一个worker.js的工作函数文件，有点麻烦。我们是不是可以更加简单一些呢？

　　在我们启动Node.js程序时，node命令可以带上-e这个参数，它将直接执行-e后面的字符串，如下代码就将打印出hello world。

node -e "console.log('hello world')"

　　合理的利用这个特性，我们就可以免去每次都创建一个文件的麻烦。

var express = require('express');
var spawn = require('child_process').spawn;
var app = express();
var spawn_worker = function(n,end){//定义工作函数
    var fibo = function fibo (n) {
      return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
    }
    end(fibo(n));
  }
var spawn_end = function(result){//定义工作函数结束的回调函数参数
    console.log(result);
    process.exit();
}
app.get('/', function(req, res){
  var n = ~~req.query.n || 1;
  //拼接-e后面的参数
  var spawn_cmd = '('+spawn_worker.toString()+'('+n+','+spawn_end.toString()+'));'
  console.log(spawn_cmd);//注意这个打印结果
  var worker = spawn('node',['-e',spawn_cmd]);//执行node -e "xxx"命令
  var fibo_res = '';
  worker.stdout.on('data', function (data) { //接收工作函数的返回
      fibo_res += data.toString();
  });
  worker.on('close', function (code) {//将结果响应给客户端
      res.send(fibo_res);
  });
});
app.listen(8124);

　　代码很简单，我们主要关注3个地方。

　　第一、我们定义了spawn_worker函数，他其实就是将会在-e后面执行的工作函数，所以我们把计算斐波那契数组的算法定义在内，spawn_worker函数接收2个参数，第一个参数n表示客户请求要计算的斐波那契数组的位数，第二个end参数是一个函数，如果计算完毕则执行end，将结果传回主线程；

　　第二、真正当Node.js脚步执行的字符串其实就是spawn_cmd里的内容，它的内容我们通过运行之后的打印信息，很容易就能明白；

　　第三、我们利用child_process的spawn方法，类似在命令行里执行了node -e "js code"，启动Node.js工作进程，同时监听子进程的标准输出，将数据保存起来，当子进程退出之后把结果响应给用户。

　　现在主要的焦点就是变量spawn_cmd到底保存了什么，我们打开浏览器在地址栏里输入：

http://127.0.0.1:8124/?n=35

　　下面就是程序运行之后的打印信息，

(function (n,end){
    var fibo = function fibo (n) {
      return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
    }
    end(fibo(n));
  }(35,function (result){
      console.log(result);
      process.exit();
}));

　　对于在子进程执行的工作函数的两个参数n和end现在一目了然，n代表着用户请求的参数，期望获得的斐波那契数组的位数，而end参数则是一个匿名函数，在标准输出中打印计算结果然后退出进程。

　　node -e命令虽然可以减少创建文件的麻烦，但同时它也有命令行长度的限制，这个值各个系统都不相同，我们通过命令getconf ARG_MAX来获得最大命令长度，例如：MAC OSX下是262,144 byte，而我的linux虚拟机则是131072 byte。

　多进程和多线程

　　大部分多线程解决cpu密集型任务的方案都可以用我们之前讨论的多进程方案来替代，但是有一些比较特殊的场景多线程的优势就发挥出来了，下面就拿我们最常见的http web服务器响应一个小的静态文件作为例子。

　　以express处理小型静态文件为例，大致的处理流程如下： 1、首先获取文件状态，判断文件的修改时间或者判断etag来确定是否响应304给客户端，让客户端继续使用本地缓存。 2、如果缓存已经失效或者客户端没有缓存，就需要获取文件的内容到buffer中，为响应作准备。 3、然后判断文件的MIME类型，如果是类似html，js，css等静态资源，还需要gzip压缩之后传输给客户端 4、最后将gzip压缩完成的静态文件响应给客户端。

　　下面是一个正常成功的Node.js处理静态资源无缓存流程图：

　　这个流程中的(2)，(3)，(4)步都经历了从js到C++ ，打开和释放文件，还有调用了zlib库的gzip算法，其中每个异步的算法都会有创建和销毁线程的开销，所以这样也是大家诟病Node.js处理静态文件不给力的原因之一。

　　为了改善这个问题，我之前有利用libuv库开发了一个改善Node.js的http/https处理静态文件的包，名为ifile，ifile包，之所以可以加速Node.js的静态文件处理性能，主要是减少了js和C++的互相调用，以及频繁的创建和销毁线程的开销，下图是ifile包处理一个静态无缓存资源的流程图：

　　由于全部工作都是在libuv的子线程中执行的，所以Node.js主线程不会阻塞，当然性能也会大幅提升了，使用ifile包非常简单，它能够和express无缝的对接。

var express = require('express');
var ifile = require("ifile");
var app = express();   
app.use(ifile.connect());  //默认值是 [['/static',__dirname]];       
app.listen(8124);

　　上面这4行代码就可以让express把静态资源交给ifile包来处理了，我们在这里对它进行了一个简单的压力测试，测试用例为响应一个大小为92kb的jquery.1.7.1.min.js文件，测试命令：

ab -c 500 -n 5000 -H "Accept-Encoding: gzip"

http://192.168.28.5:8124/static/jquery.1.7.1.min.js

　　由于在ab命令中我们加入了-H "Accept-Encoding: gzip"，表示响应的静态文件希望是gzip压缩之后的，所以ifile将会把压缩之后的jquery.1.7.1.min.js文件响应给客户端。结果如下：

Server Software:       
Server Hostname:        192.168.28.5
Server Port:            8124
Document Path:          /static/jquery.1.7.1.min.js
Document Length:        33016 bytes
Concurrency Level:      500
Time taken for tests:  9.222 seconds
Complete requests:      5000
Failed requests:        0
Write errors:          0
Total transferred:      166495000 bytes
HTML transferred:      165080000 bytes
Requests per second:    542.16 [#/sec](mean)
Time per request:      922.232 [ms](mean)
Time per request:      1.844 [ms](mean, across all concurrent requests)
Transfer rate:          17630.35 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median  max
Connect:        0  49 210.2      1    1003
Processing:  191  829 128.6    870    1367
Waiting:      150  824 128.5    869    1091
Total:        221  878 230.7    873    1921
Percentage of the requests served within a certain time (ms)
  50%    873
  66%    878
  75%    881
  80%    885
  90%    918
  95%  1109
  98%  1815
  99%  1875
100%  1921 (longest request)

　　我们首先看到Document Length一项结果为33016 bytes说明我们的jquery文件已经被成功的gzip压缩，因为源文件大小是92kb；其次，我们最关心的Requests per second:542.16 [#/sec](mean)，说明我们每秒能处理542个任务；最后，我们看到，在这样的压力情况下，平均每个用户的延迟在1.844 [ms]。

　　我们看下使用express框架处理这样的压力会是什么样的结果，express测试代码如下：

var express = require('express');
var app = express();
app.use(express.compress());//支持gzip
app.use('/static', express.static(__dirname + '/static'));
app.listen(8124);

　　代码同样非常简单，注意这里我们使用：

app.use('/static', express.static(__dirname + '/static'));

　　而不是：

app.use(express.static(__dirname));

　　后者每个请求都会去匹配一次文件是否存在，而前者只有请求url是/static开头的才会去匹配静态资源，所以前者效率更高一些。然后我们执行相同的ab压力测试命令看下结果：

Server Software:       
Server Hostname:        192.168.28.5
Server Port:            8124
Document Path:          /static/jquery.1.7.1.min.js
Document Length:        33064 bytes
Concurrency Level:      500
Time taken for tests:  16.665 seconds
Complete requests:      5000
Failed requests:        0
Write errors:          0
Total transferred:      166890000 bytes
HTML transferred:      165320000 bytes
Requests per second:    300.03 [#/sec](mean)
Time per request:      1666.517 [ms](mean)
Time per request:      3.333 [ms](mean, across all concurrent requests)
Transfer rate:          9779.59 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median  max
Connect:        0  173 539.8      1    7003
Processing:  509  886 350.5    809    9366
Waiting:      238  476 277.9    426    9361
Total:        510 1059 632.9    825    9367
Percentage of the requests served within a certain time (ms)
  50%    825
  66%    908
  75%  1201
  80%  1446
  90%  1820
  95%  1952
  98%  2560
  99%  3737
100%  9367 (longest request)

　　同样分析一下结果，Document Length:33064 bytes表示文档大小为33064 bytes，说明我们的gzip起作用了，每秒处理任务数从ifile包的542下降到了300，最长用户等待时间也延长到了9367 ms，可见我们的努力起到了立竿见影的作用，js和C++互相调用以及线程的创建和释放并不是没有损耗的。

　　但是当我在express的谷歌论坛里贴上这些测试结果，并宣传ifile包的时候，express的作者TJ，给出了不一样的评价，他在回复中说道：

请牢记你可能不需要这么高等级吞吐率的系统，就算是每月百万级别下载量的npm网站，也仅仅每秒处理17个请求而已，这样的压力甚至于PHP也可以处理掉（又黑了一把php）。

　　确实如TJ所说，性能只是我们项目的指标之一而非全部，一味的去追求高性能并不是很理智。

ifile包开源项目地址：https://github.com/DoubleSpout/ifile

　总结

　　单线程的Node.js给我们编码带来了太多的便利和乐趣，我们应该时刻保持清醒的头脑，在写Node.js代码中切不可与PHP混淆，任何一个隐藏的问题都可能击溃整个线上正在运行的Node.js程序。

　　单线程异步的Node.js不代表不会阻塞，在主线程做过多的任务可能会导致主线程的卡死，影响整个程序的性能，所以我们要非常小心的处理大量的循环，字符串拼接和浮点运算等cpu密集型任务，合理的利用各种技术把任务丢给子线程或子进程去完成，保持Node.js主线程的畅通。

　　執行緒/進程的使用並不是沒有開銷的，盡可能減少創建和銷毀執行緒/進程的次數，可以提升我們系統整體的效能和出錯的機率。

　　最後請不要一味的追求高性能和高並發，因為我們可能不需要係統具有那麼大的吞吐率。高效，敏捷，低成本的開發才是專案所需要的，這也是為什麼Node.js能夠在眾多開發語言中脫穎而出的關鍵。

相關推薦：

url傳遞參數時如何寫變數（程式碼）

JS教學--動態規劃演算法背包容量問題

關於javaScript中作用域與閉包的知識講解

#

以上是Node.js中線程和進程的詳細分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！