nodejs中實現阻塞執行個體

nodejs中實現阻塞執行個體

 這篇文章主要介紹了nodejs中實現阻塞執行個體,本文直接給出執行個體代碼,需要的朋友可以參考下

 

 

node.js中與生俱來的單線程編程、回呼函數非同步式風格讓我們有時喜有時憂。先說單線程，很多人會費解於node.js的單線程如何能做到高並發？這個問題不是本文重點，點到為止。澄清一點，node.js的單線程僅僅指javascript引擎是單線程的，無論如何我們沒有辦法在javascript中實現多線程和阻塞（本文用到的方法同樣不是通過V8引擎實現同步的）；但對於node.js的其他方面不代表不能多線程，例如IO。如果現在node.js遭受大量請求，而這些請求都是IO密集型的，那麼此時node每接受一個請求，在遇到耗時較長的IO操作時，javascript線程並不會一直在此等待，而是交出控制，在回調堆棧裡添加IO操作完成後要執行的操作（當回調層級過多，訪問數量過大，大量的回調鏈可能會爆棧）。而在這段時間內，node.js又可以處理其他請求了。所以對於node.js而言，雖然javascript是單線程的，每次只能處理一個請求，但javascript處理一個請求的時間往往較短（對於IO密集型應用而言），只要可以非同步處理，那麼在處理的過程中，此次請求都會釋放控制，使node.js能處理其他請求。這並發請求的同時，IO其實一直處於並髮狀態，減少處理請求的線程數，節約資源以增加IO的線程數，對於通常耗時很長的IO密集型請求來說，無疑能帶來效能上的提升。

前面囉囉嗦嗦地一直在強調IO密集型，其實是在強調node.js的強項。相應的，它的短板就是CPU密集型的請求。道理很簡單，javascript不會並發，只能一個請求完成後才能處理其他請求。一個請求處理的時間越長，其他請求等待的時間越長。同一時間只會有一個請求被處理，並發效能很低。

話說到這兒，我想申明一點：node.js不應該被阻塞；能非同步處理的方法非同步處理（如使用fs.readFile()，而非fs.syncReadFile()fs.readFileSync()方法）。

node中不能阻塞，並不代表node外不能阻塞。前面我們有講到fibers，現在，我們就來嘗試在fibers中實現阻塞。就以處理一個http請求為例吧：

 

複製代碼 代碼如下:

var Fiber = require('fibers');
var http = require("http");
Fiber(function () {
var httpFiber = Fiber.current;
var html = "";
http.get("http://www.baidu.com", function (res) {
var dataFiber = Fiber.current;
res.on("data", function (data) {
html += data;
});
res.on("end", function (data) {
httpFiber.run();
});
});
Fiber.yield();
console.log(html);
}).run();

 

yield()、 run()這兩個方法還不瞭解的同學，請自行查閱《fibers in node》。

fibers的運行並不在node進程中，所以在fibers內部實現阻塞對node整體的效能並沒有影響。而且實現起來也是相當容易，只需要在想阻塞的時候，把fiber yield掉。需要繼續運行，則執行 run()恢複fiber。在上面的例子中，我們希望當http.get請求發起時阻塞當前程式，當所有資料接收完成時，恢複程式。於是我們在調用http.get後使用 Fiber.yield()中斷此fiber。在對response的監聽中，如果觸發 end事件表明資料轉送完成，於是在 end的回呼函數中，調用 Fiber.current.run()恢複fiber，這樣，後續的代碼就以同步的方式拿到http.get請求的資料。

上面的樣本只是提供一種思路。如果對這種思路進行一些抽象封裝，比如說，對有接受回呼函數為參數的非同步方法呼叫進行一步柯裡化，在調用後中斷，並劫持回呼函數，以恢複程式的代碼為回呼函數。擷取非同步資料後，再程式觸發預定的回呼函數，這樣基本能實現非同步方法呼叫同步化。這段說得比較亂，基本上就是 fibers/future的實現思路，如果有興趣，請參考其原始碼。