使用Java编写的应用, 可以编程开启多线程处理高并发业务场景.
而JS处理高并发场景使用的是 : 队列机制, 事件机制
因为JS在网页中运行时单线程模式, 在服务端nodejs中运行是单进程模式, 都无法像JAVA那样开启多个线程或者协程来处理高并发任务.
但是这不意味着JS无法处理高并发任务, 单进程的程序在使用队列机制(就是待处理任务一个个排队)处理高并发场景也仍然是非常高效的, 而且避免了开启多个线程的内存消耗.但是其缺点也是很明显的 : 不适合处理单个任务计算非常复杂消耗时间的场景.
举个栗子 :
想象一下生活中排队的场景, 如果前面有一个人磨磨唧唧, 半天赖在窗口各种问问题, 后面的人都要排队等着, 很着急.
而如果开启多个窗口(多线程/进程), 那些难缠的人分到一个窗口, 速度快的人分到一个窗口, 效率就大大提升了.
1, 用 fiber 还是等语法层面的改进，我认为是见仁见智。我不认为让开发者关心一个调用是同步还是异步是一件好事情。我在微博上面说过，异步是会向上传染的，语言级的协程无法根本解决异步问题。在一个层级较深的项目里面，一旦底层中有一个模块需要同步改异步或者相反(比如需要增加一次数据库操作)，向上的每一个层级都需要在语法上进行修改，这一点是灾难的。我不认为 js 能最终解决这个问题，最后必须回归堆栈级协程。
2, 从纯 js 性能来说，fiber 比 callback 要高出非常多。fibjs 的模块之间是最简单的函数调用关系，而 callback 则需要往返两次才能完成一次调用，期间还要结果组包，错误处理，保存工作状态等等耗时操作。同时 nodejs 的事件队列也是一个性能堪忧的东西。越复杂的应用，这些影响越大。
数据库操作，没有做详细对比测试。封装 leveldb 的时候简单测试了一下，fibjs 9w/s，nodejs 3w/s。http + mongodb 有网友测试结果在这里：http://baoz.cn/499353，基本也是将近 3 倍。并且这些测试里面，fibjs 的瓶颈根本不在 fibjs 而 nodejs 则是已经跑满了。
