一、 介绍

在node中,单线程是仅针对javascript而言的,其底层其实充斥着多线程。而如果需要在javascript中实现多线程,一种常见的做法是编写C++ addon,绕过javascript的单线程机制。不过这种方法提升了开发调试的难度和成本。像其他很多脚本语言,我们也可以把纤程的概念引入到node中。

二、使用

node-fibers

node-fibers这个库就为node提供了纤程的功能。多线程方面没有测试出理想的结果,不过在异步转同步作用显著,也许在减少node调用堆栈、无限递归方面也会有价值可挖。本文档主要介绍 node-fibers库的使用方法和异步转同步等内容。

安装

node-fibers是采用C语言编写,直接下载源码需要编译,通常直接npm安装即可,代码如下:

  1. npm install fibers


fibers库的使用(API)

  1. Fiber(fn)/ new Fiber(fn)

创建一个纤程,可以当成构造函数使用,也可以当成普通函数调用。代码如下:

  1. function fibo(n) {
  2. return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
  3. }
  4. Fiber(function () {
  5. console.log(fibo(40));
  6. });

当 run()调用的时候,纤程启动,并为 fn分配新的堆栈, fn会在这个新的堆栈上运行,直到 fn有返回值或调用 yield()。 fn返回后或调用 yield()后,堆栈重置,当再次调用 run()时,纤程会再次启动, fn运行于首次分配的堆栈中。

  1. Fiber.current

获得当前纤程,并可对其进行操作。如果指定一个变量与其相关联,请务必确保此纤程能够释放,否则V8的垃圾回收机制会一直忽略这部分的内存,造成内存泄漏。

  1. Fiber.yield(param)

前面的说明中已经提及过这个函数。 yield()方法用于中断纤程,一定程度上类似 return。一旦执行 yield(),则此 Fiber中后续代码将没有机会执行,例如:

  1. var fiber = Fiber(function () {
  2. console.log("Fiber Start");
  3. Fiber.yield();
  4. console.log("Fiber Stop");
  5. }).run();
  6. // 输出: "Fiber Start"

执行后只会输出“Fiber Start”,后一个输出命令没有执行。如果向 yield()传入参数,那么此参数作为 run()的返回值。

  1. var fiber = Fiber(function () {
  2. Fiber.yield("success");
  3. }).run();
  4. console.log(fiber); // -> "success"
  1. Fiber.prototype.run(param)

这个方法已经很熟悉了,之前隐约有提及调用 run()的两种时态,一是Fiber未启动时,一是Fiber被yield时。在这两种时态下, run()的行为并不太一样。当Fiber未启动时, run()接受一个参数,并把它传递给 fn,作为其参数。当Fiber处理yielding状态时, run()接受一个参数,并把它作为 yield()的返回值,fn并不会从头运行,而是从中断处继续运行。关于 fn、 yield、 run三者的参数、返回值等关系,可以通过下面的小例子来说明:

  1. var Fiber = require('fibers');
  2. var fiber = Fiber(function (a) {
  3. console.log("第一次调用run:");
  4. console.log("fn参数为:" + a);
  5. var b = Fiber.yield("yield");
  6. console.log("第二次调用run:");
  7. console.log("fn参数为:" + a);
  8. console.log("yield返回值为:" + b);
  9. return "return";
  10. });
  11. // 第一次运行run()
  12. var c = fiber.run("One");
  13. // 第二次运行run()
  14. var d = fiber.run("Two");
  15. console.log("调用yield,run返回:" + c);
  16. console.log("fn运行完成,run返回:" + d);
  17. // 输出如下:
  18. // 第一次调用run:
  19. // fn参数为:One
  20. // 第二次调用run:
  21. // fn参数为:One
  22. // yield返回值为:Two
  23. // 调用yield,run返回:yield
  24. // fn运行完成,run返回:return

从上面例子中,可以很明显看出 yield的使用方法与现在的javascript的语法相当不同。在别的语言中(C#、Python等)已经实现了 yield关键字,作为迭代器的中断。不妨在node上也实现一个迭代器,具体体会一下 yield的使用。还是以开头的斐波那契数列为例:
复制代码 代码如下:

  1. var fiboGenerator = function () {
  2. var a = 0, b = 0;
  3. while (true) {
  4. if (a == 0) {
  5. a = 1;
  6. Fiber.yield(a);
  7. } else {
  8. b += a;
  9. b == a ? a = 1 : a = b - a;
  10. Fiber.yield(b);
  11. }
  12. }
  13. }
  14. var f = new Fiber(fiboGenerator);
  15. f.next = f.run;
  16. for (var i = 0; i < 10; i++) {
  17. console.log(f.next());
  18. }
  19. /*
  20. 1
  21. 1
  22. 2
  23. 3
  24. 5
  25. 8
  26. 13
  27. 21
  28. 34
  29. 55
  30. */

有两个问题需要留意,第一, yield说是方法,更多地像关键字,与 run不同, yield不需要依托Fiber实例,而 run则需要。如果在Fiber内部调用 run,则一定要使用: Fiber.current.run();第二, yield本身为javascript的保留关键字,不确定是否会、何时会启用,所以代码在将来可能会面临变更。

  1. Fiber.prototype.reset()

我们已经知道Fiber可能存在不同的时态,同时会影响 run的行为。而 reset方法则不管Fiber处理什么状态,都恢复到初始状态。随后再执行 run,就会重新运行 fn。

  1. Fiber.prototype.throwInto(Exception)

本质上 throwInto会抛出传给它的异常,并将异常信息作为 run 的返回值。如果在Fiber内不对它抛出的异常作处理,异常会继续冒泡。不管异常是否处理,它会强制 yield,中断Fiber。

future库的使用

在node中直接使用Fiber并不一直是合理的,因为Fiber的API实在简单,实际使用中难免会产生重复冗长的代码,不利于维护。推荐在node与Fiber之间增加一层抽象,让Fiber能够更好地工作。 future库就提供了这样一种抽象。 future库或者任何一层抽象也许都不是完美的,没有谁对谁错,只有适用不适用。比如, future库向我们提供了简单的API能够完成异步转同步的工作,然而它对封装 generator (类似上面的斐波那契数列生成器)则无能为力。

future库不需要单独下载安装,已经包含在 fibers库中,使用时只需要 var future=require(‘fibers/future’) 即可。

API

  1. Function.prototype.future()

给 Function类型添加了 future方法,将function转化成一个“funture-function”。

  1. var futureFun = function power(a) {
  2. return a * a;
  3. }.future();
  4. console.log(futureFun(10).wait());

实际上 power方法是在Fibel内执行的。不过现有版本的 future有bug,官方没有具体的说明,如果需要使用此功能,请删除掉 future.js的第339行和第350行。

  1. new Future()

Future对象的构造函数,下文详细介绍。

  1. Future.wrap(fn, idx)

wrap方法封装了异步转同步的操作,是 future库中对我们最有价值的方法。 fn表示需要转换的函数, idx表示 fn接受的参数数目,认为其 callback方法为最后一个参数(这边API的制定颇有争议,有人倾向传递 callback应该处于的位置,好在 wrap方法比较简单,可以比较容易修改代码)。看一个例子就能了解 wrap的用法:

  1. var readFileSync = Future.wrap(require("fs").readFile);
  2. Fiber(function () {
  3. var html = readFileSync("./1.txt").wait().toString();
  4. console.log(html);
  5. }).run();

从这个例子中可以看出Fiber异步转同步确实非常有效,除了语法上多了一步 .wait()外,其他已经 fs提供的 fs.readFileSync方法别无二致了。

  1. Future.wait(futures)

这个方法前面已经多次看到了。顾名思义,它的作用就是等待结果。如果要等待一个future的实例的结果,直接调用 futureInstance.wait()即可;如果需要等待一系列future实例的结果,则调用 Future.wait(futuresArray)。需要注意的是,在第二种用法中,一个future实例在运行时出现错误, wait方法不会抛出错误,不过我们可以使用 get()方法直接获取运行结果。

  1. Future.prototype.get()

get()的用法与 wait()的第一种方式很像,所不同的是, get()立刻返回结果。如果数据没有准备好, get()会抛出错误。

  1. Future.prototype.resolve(param1,param2)

上面的的 wrap方法总给人以一种 future其实在吞噬异步方法的回调函数,并直接返回异步结果。事实上 future也通过 resolve方法提供设置回调函数的解决方案。 resolve最多接受两个参数,如果只传入一个参数, future认为传了一个node风格的回调函数,例如如下示例:

  1. futureInstance.resolve(function (err, data) {
  2. if (err) {
  3. throw err;
  4. } else {
  5. console.log(data.toString());
  6. }
  7. });

如果传入两个参数,则表示对错误和数据分别做处理,示例如下:
复制代码 代码如下:

  1. futureInstance.resolve(function (err) {
  2. throw err;
  3. }, function (data) {
  4. console.log(data.toString());
  5. });

另外 future并不区分 resolve的调用时机,如果数据没有准备好,则将回调函数压入队列,由 resolver()方法统一调度,否则直接取数据立即执行回调函数。

  1. Future.prototype.isResolved()

返回布尔值,表示操作是否已经执行。

  1. Future.prototype.proxy(futureInstance)

proxy方法提供一种 future实例的代理,本质上是对 resolve方法的包装,其实是将一个instance的回调方法作为另一个instance的回调执行者。例如:

  1. var target = new Future;
  2. target.resolve(function (err, data) {
  3. console.log(data)
  4. });
  5. var proxyFun = function (num, cb) {
  6. cb(null, num * num);
  7. };
  8. Fiber(function () {
  9. var proxy = Future.wrap(proxyFun)(10);
  10. proxy.proxy(target);
  11. }).run(); // 输出100

虽然执行的是 proxy,但是最终 target的回调函数执行了,并且是以 proxy的执行结果驱动 target的回调函数。这种代理手段也许在我们的实际应用中有很大作用,我暂时还没有深入地思考过。

  1. Future.prototype.return(value)

  2. Future.prototype.throw(error)

  3. Future.prototype.resolver()

  4. Future.prototype.detach()

以上四个API呢我感觉相对于别的API,实际使用的场景或作用比较一般。 return和 throw都受 resolver方法调度,这三个方法都很重要,在正常的future使用流程中都会默默工作着,只是我没有想出具体单独使用它们的场景,所以没有办法具体介绍。 detach方法只能算 resolve方法的简化版,亦没有介绍的必要。