在内部使用线程的时候，Node.js是如何固有的更快？
参考以下讨论： 当Node.js仍然依赖于内部的线程时，Node.js如何更快地运行？
在经历了所有的回应之后，我仍然有一些基本的问题：如果一个数据库调用被发出，“某人”不得不阻止该调用返回。 它变成了一个内部阻塞。 有人必须打电话给数据库。 “有人”必须是一个线索。 如果有50个数据库调用，尽pipe它们似乎对Javascript没有阻塞，但它们都被阻塞了。 如果有50个调用，他们全部在DB上被一起解雇，他们必须被每个线程发送到DB。 这意味着将有50个线程发送数据库调用并等待他们的调用返回。 这与在Apache中使用50个线程没有区别。 请纠正我的理解。 什么是Node.js巧妙地做，以及如何确保在这种情况下，less于50线程运行？
你是……部分正确的。 如果有50个并发的数据库调用，那么这意味着50个线程，每个线程专用于一个数据库调用（实际上，事实上， 默认情况下 ，节点在其线程池中只提供4个并发线程，如果您需要更多，则必须明确指定你愿意让多less个线程允许节点启动;看到我的答案在这里 – 任何多余的请求排队）。
比Apache更高效的是，每个线程都是专用于最小的function单元的，它只能在数据库调用的整个过程中生效，然后被放弃（在这种情况下，创build一个新的线程，到极限，然后该线程被放回到池中）。 这与Apache有很大的对立，Apache为每个新的请求分配了一个线程，并且可能需要服务多个数据库调用和其他处理，直到请求完成，然后放弃。
最终，这导致每个线程花更多的时间在工作或在池中等待更多的工作，更less的时间闲置和不可用。
请注意，这是依赖于工作负载的，在Apache模型中存在工作负载更好的工作负载，但总的来说， 大多数 web风格工作负载更适合于节点模型。
不同的是，我相信像apache这样的东西，这些线程将按照接收到的顺序进行处理。 因此，如果线程正在等待10TB的数据，而线程2只等待10KB的数据，则线程2必须等待线程1完成，即使工作可以做得更快，返回更快。 使用节点的想法是每个等待I / O的线程在完成后立即返回。 因此，根据I / O，相同的情况可能允许线程2在线程完成之前返回。 这是比较老，但仍然是一个优秀的写作，我相信线程在节点。 http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/