因为并发数受带宽及其它很多因素影响，不能单就node.js来说并发多高。
如果无限带宽，无限计算力，无限存……你可以认为node.js并发数也是无限的，但这没有意义，在同样的情况下，就算是IIS，并发数也可以认为是无限的。
node.js的优势严格来说不是并发而是“非阻塞”。它是通过非阻塞来达到高并发的目标的，我们用node.js也是用它的非阻塞这个特点。
在优化线程池，以及端口复用等技术的基础上，对于简单的业务处，使用其它的模型也可以达到高并发的目标，但在面临业务逻辑耗时长的问题时，node.js的优势就比较明显。
如果一个事务请求涉及三个业务逻辑，比如登录(login)这个事务，假设我们定义它有三个业务逻辑：
verify：验证用户是否合法（用户名，密码什么的）；
user:获取身份信息（权限什么的）；
modules:返回他可用的业务接口列表(商品管理，用户管理，订单审核等）
我们假设：只有1完成了才可以进行2，2完成了才可以进行3，上述每个业务逻辑都需要1秒去完成（客户的登录请求这个事务需要3秒才能完成）。
同时，我们也假设，这三个业务逻辑服务都是在其它的服务器上，它们的并发数无上限。
然后，我们在“一瞬间”我向这个服务发出1000个login请求
那么，我们来看看node.js与纯java的不同。
nodejs调用它们来完成,因为它是非阻塞的，它调了verify后，不再等待它返回结果，就可以处理另一个事务请求了，当verify请求有返回结果时，它再来处理结果，决定是否调用user……，整个过程，只在一个进程中就完成了。
它收到这1000个请求后，在这个进程中向verify发出了1000个请求，过了一秒，收到回应又有900个验证成功，它返回了100个登录失败的信息，并向user发出了900个请求，又过了一秒，返回了900个modules的结果。
这样的结果，在客户端看来，发出请求后1秒，收到了100个登录失败，又过了两秒，收到了900个可用功能列表（因为异步机制，它还会稍微长一点点，假设是3.003秒吧）
现在，在带宽与计算力不受限的情况下，同样的内存，看看纯Java是怎么个情况。如果使用纯java来做这个事，java不使用异步模式的话，一个线程响应一个请求。
java同样“一瞬间”收到了1000个请求，java开启了1000个线程去响应它们,然后这1000个线程在第一秒里都在等待verify，第一秒结束时，返回100个登录失败，关闭了100个线程，又过了两秒，900个线程得到了各自的modules结果，并返回给客户端。
对于客户端来说，感觉就是3秒，没有那个0.003。
好，至此，node.js与纯java的区别已经很明显了。纯java在不使用非阻塞机制的情况下，它需要开启1000个线程（或者进程，这个成本更高）而node.js则需要更多的时间。
在内存受限的情况下，node.js就有优势了。
假设一个进程需要1M内存，为了能同时开1000进程，你需要额外的1G内存来给它。而对于node.js，它可能只需要20M来完成这个事，代价就是每个客户端都需要多等那么一小会。
严格来说，并不提倡在node.js中实现业务逻辑，node.js最好是只用于以非阻塞模式连接多个阻塞模式的业务逻辑。
单线程解决高并发的思路就是采用非阻塞，异步编程的思想。简单概括就是当遇到非常耗时的IO操作时，采用非阻塞的方式，继续执行后面的代码，并且进入事件循环，当IO操作完成时，程序会被通知IO操作已经完成。主要运用JavaScript的回调函数来实现。多线程虽然也能解决高并发，但是是以建立多个线程来实现，其缺点是当遇到耗时的IO操作时，当前线程会被阻塞，并且把cpu的控制权交给其他线程，这样带来的问题就是要非常频繁的进行线程的上下文切换。
