居然给转这边了，统一回复一下吧。

这并不是一次严肃的对比测试，只是一时兴起测着玩的，不必认真。简单说结果吧，孢子社区已经在 fibjs 上开发了数万行代码的服务器应用，并且稳定运行一年多。

有同学看见锁就惊恐，是不对的。nodejs 在需要资源受限时同样需要锁，并且异步锁的实现令人作呕。协程的好处是你不需要对内存加锁，但是不代表你不需要对资源加锁。比如限定数据库连接数，阻止缓存重复更新，等等，很多高级场景都是需要锁来保障的。

同时，nodejs 从来就不是单线程，同样是单线程 v8 + 后台多线程，与 fibjs 相同，并且 nodejs 的 http parse 也是 c 写的。至于说 nodejs 也可以通过 addon 来提升性能，那就强词夺理了哈哈。

最后用我在 fibjs 论坛里的一段回复结束吧：

高并发不等于高性能，随着应用层逻辑的引入，会拉平甚至拉低不同平台的并发性能，越复杂的应用，对语言本身的运算速度依赖越大。

因此拿简单的 echo 来对比并发其实是没有意义的，不同语言，开发环境，最后实际上瓶颈根本都不在基础架构上，大部分应用最后每秒能响应 100 个请求便算上很好了，基础架构每秒 5000 还是 50000 对此影响很小。

所以结论是应用开发框架比并发性能是一件很蛋疼的事情，开发范式的改变带来的应用可读性，模块低耦合，容易工程化所带来的性能提升反而收益更高。

何况 fibjs 就连基础的并发性能也秒杀 nodejs 哈哈。

@ravenwang 例子我说了，当你需要限制数据库连接的时候，或者缓存失效，需要更新缓存，但是多个请求同时请求，导致多次不必要的更新请求。

你说的都是真理，如果你把 fibjs 做的事情按照 fibjs 的方式在 nodejs 上做一遍，当然没有迁移到 fibjs 的理由。你赢了哈哈。

不过前提是你先写 4万行 c++ 代码。

@goodkids fibjs 和 nodejs 都是基于 v8 的，这一点没有区别。fibjs 每周都会跟踪最新的 v8 升级。

@ravenwang 建议深度试用 Generator 之后再做比较。

@ravenwang 另外，fibjs 不是仅仅提供了 coroutine 这么简单。fibjs 实现了一整套同步 io 模块，网络模块，数据库接口等等，是一套完整的开发框架。

如果只是 v8 + coroutine，两百行就写出来了。你把 node 挂上 coroutine 包，面对一大堆不能用 coroutine 的各种 io, net, db 模块，你能干什么？

@tulayang fibjs 和 go 的模式是一样的，后台全部异步，前台面对开发者，将异步映射为同步协程。

协程方式上，fibjs 也是采用与 go 同样的模式，不是使用 gen 伪造协程，而是通过栈切换完整保存现场。这样的好处是在 javascript 层完全不必考虑实现方式，只需要按照最直接的思维方式写出业务逻辑即可。

@ravenwang 说 fibjs 比 node 异步更狠还是蛮准确的，fibjs 的工作线程是全部由 c++ 完成的异步逻辑。换句话说 Node 是在用户线程异步，fibjs 则是把异步延伸到后台大量工作线程。

不过 @ravenwang 说同步只是写代码方式这一点不准确，如前所述，fibjs 不是语法上的技巧，而是硬碰硬地切换堆栈。所以不是写代码方式不同，而是 javascript 代码实实在在就是同步的。

@ravenwang 就是这样的

@ravenwang 接受批评呵呵

@tulayang “形式上同步实质上却是异步执行”，你每天使用的操作系统每时每刻都是这样运行的。

@tulayang 好吧我做个类比。fibjs 的工作原理跟 goroutine 是完全一样的。

@ravenwang 我也遁了，跟一个 bug 较劲呢。

@tulayang bug 没搞掂，回来说两句。

首先，fibjs 不是语法糖，跟你见过的其他各种 js 伪同步的东西不一样。另外，并发不论是多进程还是多线程，都是在操作系统协调下的后台异步前台同步，你的文件读写，控制台输入输出，甚至同步网络操作，都不会出现你说的等待的时候 cpu 等在那里的情况。因为操作系统在发现同步线程需要等待的时候，便保存现场，把 cpu 分配给别的线程了，等底层异步完成后，再触发事件唤醒等待的线程或进程。

fibjs 采用的是用户空间线程技术，windows 上也叫纤程，这个其实是很古老的技术，远在 Linux pthread 出现以前，就有一个叫 pth 的项目 帮助 Linux 程序员实现纤程。这种用户空间线程不同于操作系统线程，是非抢先的，必须依赖于各个纤程主动交出控制权，其他纤程才可以被唤醒。

pthead 出现之后，这种技术慢慢被人淡忘，直到大家越来越发现在应用层处理多线程带来的运行成本和程序员不熟练带来的风险。

异步处理便是一种尝试，不过也并不是什么新技术，哪怕最古老的操作系统，内部实现也都是异步的。unix select 开始把这种范式带到应用层，windows gui 的消息处理也是异步编程，其它的比如 Windows 的完成函数，iocp，linux 后来赶上的 epoll，freebsd 的 equeue，都是运用了十几甚至几十年的技术了。

然而毕竟异步是非人类的。于是越来越多的架构开始努力不那么异步，nodejs 社区便做了很多努力。而目前为止，最让人称道的恐怕算是 go 的 goroutine 了，goroutine 便是典型的用纤程来实现用户层同步，基础库异步的方案。而 javascript 以纤程为基础提供完整解决方案的 唯 fibjs 一家，nodejs 虽说也有第三方 coroutine 模块，但是只实现了最基础的纤程处理，而整个 nodejs 生态都是建立在异步基础上的，导致 coroutine 根本不能发挥，因此几乎一发布便被遗弃了。

用户空间线程因为是非抢先的，意味着不会出现多个纤程同时修改和访问内存，不会出现多线程开发的绝大多数风险，但是缺点是因为所有纤程其实共享一个物理线程，所以也会出现 nodejs 一样的运算瓶颈。

针对这个情况，fibjs 的策略是只在极少数必须的运算采用纤程，而所有可能需要大量运算，或者需要等待的 io，都投射到后台工作线程，或者异步完成，尽可能把宝贵的 javascript 线程的运行时间留给业务逻辑，从而最大化 cpu 利用率。

这样做的代价便是 fibjs 的基础库很难像 nodejs 那样大量使用 javascript 实现，只能用 c++ 完成几乎全部基础库。

@bnuhero fibjs 和 JXCore 解决的问题是不同的。JXCore 试图解决 nodejs 单线程瓶颈，他的实现方式比较简单，是在进程中开启多个 v8 内核，各自在自己的空间和线程内工作，好处是可以充分利用多核(类似 cluster 的单进程版)，缺点是每个 v8 内核是独立的，内核之间传递变量，函数，共享，都必须经过处理，简单来说就是进程内的 rpc。

@ravenwang fibjs 因为 异步-> 同步转换的原因，其实很多地方性能是低于 nodejs 的，但是实测起来，性能却高于 nodejs，根本原因，还是编程范式的改善，极大简化了业务逻辑，带来的性能提升。

同时 fibjs 还会转化工作方式，在只发现一个纤程时，不需要使用后台线程，则自动选择纯同步模式，以避免不必要的任务切换负载。

比如同样的 leveldb 封装，多纤程下，fibjs 性能是 nodejs 的三倍，单纤程下，则是 nodejs 的接近 9 倍。(这个话题拜托别展开，我只是发现封装后性能比 leveldb 官方声称低一个数量级，才找来 nodejs 的封装测一下的，同样不是认真的性能对比测试，不必认真)

这一点在业务逻辑层尤为重要，简化的编程范式带来的性能提升，反而远大于核心库优化带来的性能提升。毕竟绝大多数应用的瓶颈，其实都是复杂的业务逻辑，而非核心库本身。

@XadillaX 这个问题我在上面说过：

javascript 以纤程为基础提供完整解决方案的 唯 fibjs 一家，nodejs 虽说也有第三方 coroutine 模块，但是只实现了最基础的纤程处理，而整个 nodejs 生态都是建立在异步基础上的，导致 coroutine 根本不能发挥，因此几乎一发布便被遗弃了。

同时，fibjs 生态的确比不过 nodejs，这一点必须承认，哑口无言哈哈。

@tulayang 你是不是不知道 fiber 是什么？

@zalemwoo 哈哈，完整当然是相对的，这里指的是开箱即用，是有完整的多任务调度和并发控制，完整的并发文件 io 和 网络 io，一套完备的 http 客户端服务器端解决方案，ssl 支持，以及数据库支持。

对于绝大多数场景，fibjs 的基础库已经足够应付了。

@tulayang 看来的确不了解，建议学习一下 goroutine，熟悉 c 的话学习一下 linux 的 getcontext, makecontext 和 swapcontext，熟悉 windows 的话了解一下 Fibers。

fibjs 为了保证可移植性，连这些都没用，是自己实现的 fiber。但是原理都是一样的。

再说一句，windows 的 fiber 的历史有快 20 年了，Linux 的 context 历史可能也有十年了。我前面提到的 pth 是在 linux 支持线程之前便有的方案，但是实在太久远，不建议了解了。

@tulayang 明白了

@SeanLiangYoung

function func() {
}

func.start();

便会创建一个纤程，将 func 作为入口，并加入调度列表，当有纤程出让控制权时，此函数便会被执行。切换方式是保存全部 cpu 寄存器，加载目标纤程的 cpu 寄存器，恢复 ip 和 sp。这是标准的纤程处理方式。

@slightboy Windows 在 vs 2013 上编译测试的。之前发布过二进制，不过因为项目一直在更新，二进制发布总是滞后，后来便没做了。

@guoguofish 文档在这里： http://prj.baoz.cn/docs/fibjs/annotated.html

@JacksonTian 赞认真！

@iwinmin 楼上还提交了一个 mongodb 补丁。

@withinsea fibjs 是这样的

var fs = require('fs');
console.log(fs.readFile('in.txt', 'utf-8'));

@wuliao49 翻来覆去考虑很久，最后决定不去兼容 nodejs 的 api。

一、完全兼容工作量太大，还要支持丑陋的回调，太让人反胃。 二、还有很多事情要做，从我的项目而言，计划中的模块比兼容 nodejs 价值要大得多。 三、node 巨大部分模块稍作修改便可使用，没有大家想象中的那么不兼容。

@captainblue2013 同步或者异步，只是事务的运行方式，并不是事务的逻辑，所有事务的逻辑都是以同步方式描述的。异步编程，实际上是把同步描述好的业务逻辑投射到事件处理函数内。不用讨论，这确定是反人类思维方式的。