node從他推出至今，充滿讚美和飽受詬病的都是其單執行緒模型，所有的任務都在一個執行緒中完成（I/O等例外），優勢的地方自然是免去了頻繁切換執行緒的開銷，以及減少資源互搶的問題等等，但是當nodejs面對cpu密集型模型的時候就力不從心了。儘管node擁有非同步機制，可以把一些耗時演算法丟入eventloop等待下個事件迴圈再做，但是因為其任然是單執行緒模型，所以終究會造成阻塞。

先解釋一下兩個名詞，Fibers 和 Threads。
Fibers 又稱纖程，可以理解為協同程式，類似py和lua都有這樣的模型。使用Fibers可以避免對資源的互搶，減少cpu和記憶體的消耗，但是Fibers並不能夠真正的並行執行，同一時刻只有一個Fibers在執行，如果在其中一個Fibers中執行過多的cpu操作或者寫了個死迴圈，則整個主程式將卡死住。node中的非同步事件迴圈模型就有點象這個。

Threads 又稱執行緒，他可以在同一時刻並行的執行，他們共享主程序的記憶體，在其中某一時刻某一個threads鎖死了，是不會影響主執行緒以及其他執行緒的執行。但是為了實現這個模型，我們不得不消耗更多的記憶體和cpu為執行緒切換的開銷，同時也存在可能多個執行緒對同一記憶體單元進行讀寫而造成程式崩潰的問題。

很多讓node支援多執行緒的方法是使用c/c++的addon來實現，在需要進行cpu密集型計算的地方，把js程式碼改寫成c/c++程式碼，但是如果開發人員對c++不是很熟悉，一來開發效率會降低不少，二來也容易出bug，而且我們知道在addon中的c++程式碼除了編譯出錯外，是很難除錯的，畢竟沒有vs除錯c++程式碼方便。

令人振奮的訊息，我們為什麼不讓node也支援多執行緒模型呢？於是Jorge為我們開發出了一個讓node支援多執行緒模型的模組：threads_a_gogo
github地址：https://github.com/xk/node-threads-a-gogo

有了threads-a-gogo（以下簡稱TAGG）這個模組之後，我們可以讓node做更多的事情，我記得以前我看過一篇文章，說node只能應付i/o密集型場景，在cpu密集型場景將完敗給apache，因為apache是為每一個請求起一條執行緒的，所以在處理cpu密集型任務時一個執行緒的高強度計算不會很大程度的影響其他執行緒，類似的還有php的fastcgi，這也是很多拿node和php進行比較時，php的擁護者們一直提出的理論。

我們先來做一個簡單的測試，用我們suqian大大最喜歡的斐波那契陣列來看一下，加入了多執行緒的node有多麼的強悍：（測試機器為4CPU）
沒有使用TAGG的正常情況，非同步也幫不了我們應對cpu密集型任務

function fibo (n){return n >1? fibo(n -1)+ fibo(n -2):1;}var n=8function back(){if(!--n)return console.timeEnd('no thread');}
    console.time('no thread');

    process.nextTick(function(){
        console.log(fibo (40));
        back();})
    process.nextTick(function(){
        console.log(fibo (40));
        back();})
    process.nextTick(function(){
        console.log(fibo (40));
        back();})
    process.nextTick(function(){
        console.log(fibo (40));
        back();})

    process.nextTick(function(){
        console.log(fibo (40));
        back();})

process.nextTick(function(){
    console.log(fibo (40));
    back();})
process.nextTick(function(){
    console.log(fibo (40));
    back();})
process.nextTick(function(){
    console.log(fibo (40));
    back();})

我們模擬了8個非同步的行為，測試用的node v0.8.16版本，所以 process.nextTick還是非同步方法。最後我們輸出結果為：

165580141165580141165580141165580141165580141165580141165580141165580141no thread:23346ms

接下來我們使用TAGG模組來測試同樣的執行8次斐波那契陣列計算，看看成績如何？

function fibo (n){return n >1? fibo(n -1)+ fibo(n -2):1;}
console.time('8 thread');var numThreads=8;//建立執行緒池，最大數為8var threadPool=require('threads_a_gogo').createPool(numThreads).all.eval(fibo);//為執行緒池註冊程式var i=8;var cb =function(err,data){//註冊執行緒執行完畢的回撥函式
    console.log(data);if(!--i){
        threadPool.destroy();
        console.timeEnd('8 thread');}}
threadPool.any.eval('fibo(40)', cb);//開始向執行緒池中執行fibo(40)這個任務

threadPool.any.eval('fibo(40)', cb);

threadPool.any.eval('fibo(40)', cb);

threadPool.any.eval('fibo(40)', cb);

threadPool.any.eval('fibo(40)', cb);

threadPool.any.eval('fibo(40)', cb);

threadPool.any.eval('fibo(40)', cb);

threadPool.any.eval('fibo(40)', cb);

最重的結果：

1655801411655801411655801411655801411655801411655801411655801411655801418 thread:9510ms

相比不使用多執行緒模型的node，使用了TAGG模組之後，我們在4CPU伺服器上的測試結果要快上一倍還不止。
到這裡我們看上去找到了一個比較完美的解決方案應對CPU密集型任務，但是可能有同學會說，我可以使用cluster來做相同的事情，下面我們來做一個使用cluster計算這些任務的情況：

var cluster =require('cluster');var numCPUs =8;function fibo (n){return n >1? fibo(n -1)+ fibo(n -2):1;}
console.time('8 cluster');if(cluster.isMaster){// Fork workers.for(var i =0; i < numCPUs; i++){
    cluster.fork();}var i =8;
  cluster.on('exit',function(worker, code, signal){if(!--i){
            console.timeEnd('8 cluster');
            process.exit(0);}});}else{
    console.log(fibo (40));
    process.exit(0);}

程式碼上的複雜程度比使用TAGG要高的多，而且如果是動態計算斐波那契陣列的結果，編碼將更加困難，需要在fork時掛上不同的引數，出錯的機率也更大。同時還有更重要的一個事情，如果是建立一個http伺服器，如果4個cluster都在計算fibo，那第5個請求node將無法處理，而是用TAGG則還是能夠正常處理的，所以cluster並不能解決單執行緒模型的cpu密集計算帶來的阻塞問題，我們看下測試結果：

1655801411655801411655801411655801411655801411655801411655801411655801418 cluster:11925ms

TAGG模組還有其他更多的功能，比如事件觸發，平滑退出，檢視執行緒工作狀態等等，總之TAGG模組給node注入了新的活力，讓node一直飽受詬病的處理cpu密集任務問題得到了一個妥善的解決，就算你不擅長c++程式碼，也能夠輕鬆編寫出多執行緒的真正的非阻塞node程式了。