使用Java编写的应用, 可以编程开启多线程处理高并发业务场景.
而JS处理高并发场景使用的是 : 队列机制, 事件机制
因为JS在网页中运行时单线程模式, 在服务端nodejs中运行是单进程模式, 都无法像JAVA那样开启多个线程或者协程来处理高并发任务.
但是这不意味着JS无法处理高并发任务, 单进程的程序在使用队列机制(就是待处理任务一个个排队)处理高并发场景也仍然是非常高效的, 而且避免了开启多个线程的内存消耗.但是其缺点也是很明显的 : 不适合处理单个任务计算非常复杂消耗时间的场景.
举个栗子 :
想象一下生活中排队的场景, 如果前面有一个人磨磨唧唧, 半天赖在窗口各种问问题, 后面的人都要排队等着, 很着急.
而如果开启多个窗口(多线程/进程), 那些难缠的人分到一个窗口, 速度快的人分到一个窗口, 效率就大大提升了.
同一套业务逻辑，实现一个webservice中间接口，中间涉及memcached和mogodb的一些操作。分别在Node.js和JAVA平台实现，java代码部署在Tomcat 7.0上，用Apache jmeter进行压力测试。
得到的测试结果很是出乎意料，Node.js的高并发优势为什么没有体现出来呢？？？
操作系统：CentOS 6.4（虚拟机）
内存：1.5G
CPU：单核
并发数 100
ramp-up period(in seconds)1
执行次数 10
以下是测试结果：
Lable #Sample Average Median 90%LineMin Max Error% Throughput KB/sec
Node.js HTTP请求 1000333 369 485 1 956 0.0 183.3180568285976 40.995932630614114
Tomcat HTTP请求 1000489 1882563 0.0 183.4862385321101 58.414564220183486
可以看到Node.js的平均执行时间为333毫秒，Tomcat的执行时间为48毫秒，Tomcat比Node.js快了近7倍！
补充1：即使是测试接口直接返回，不涉及后续的操作，Tomcat也比Node.js快了很多，求各位大神给个解释。
补充2：修改jmeter 的 ramp-up period的测试条件，比如这个值增大（如10秒），node.js的执行效率变高了，但这么想来也是违背了高并发的特性
抛砖引玉，一起探讨问题。如果你也感兴趣，不妨拿出点时间来写一段程序测试一下，我希望能得到不一样的结果。
单线程解决高并发的思路就是采用非阻塞，异步编程的思想。简单概括就是当遇到非常耗时的IO操作时，采用非阻塞的方式，继续执行后面的代码，并且进入事件循环，当IO操作完成时，程序会被通知IO操作已经完成。主要运用JavaScript的回调函数来实现。多线程虽然也能解决高并发，但是是以建立多个线程来实现，其缺点是当遇到耗时的IO操作时，当前线程会被阻塞，并且把cpu的控制权交给其他线程，这样带来的问题就是要非常频繁的进行线程的上下文切换。
