当Node.js内部仍依赖于Threads时，其固有速度如何？

Question

我刚刚观看了以下视频：Node.js简介，但仍然不了解如何获得速度优势。

主要是，有一点Ryan Dahl（Node.js的创建者）说Node.js是基于事件循环的，而不是基于线程的。线程很昂贵，只应留给并行编程专家使用。

后来，他然后展示了Node.js的体系结构栈，该体系结构栈具有基础的C实现，该实现在内部具有自己的线程池。因此，显然，Node.js开发人员永远不会启动自己的线程或直接使用线程池…他们使用异步回调。我很明白。

我不明白的是，Node.html" target="_blank">js仍在使用线程…只是在隐藏实现，因此，如果50个人很好地请求50个文件（当前不在内存中），那么不需要50个线程，这样做会更快吗？
？

唯一的区别是，由于它是在内部进行管理的，因此Node.js开发人员不必编写线程详细信息，但在其下面仍在使用线程来处理IO（阻止）文件请求。

那么，您难道不是真的只遇到一个问题（线程）并在该问题仍然存在时将其隐藏：主要是多个线程，上下文切换，死锁等吗？

必须有一些我仍然不明白的细节。

Answer 1

实际上，这里合并了一些不同的东西。但这始于模因，即线程真的很难。因此，如果它们很困难，则使用线程的可能性更大：1）由于错误而中断，2）不能尽可能高效地使用它们。（2）是您要问的那个。

考虑一下他提供的示例之一，其中有一个请求进入，您运行了一些查询，然后对结果进行一些处理。如果以标准的程序方式编写，则代码可能如下所示：

result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );

如果传入的请求导致您创建了一个运行上述代码的新线程，则您将有一个线程坐在那里，而在query()运行时则什么也不做。（根据Ryan所说，Apache正在使用一个线程来满足原始请求，而在他正在谈论的情况下，nginx却表现不佳，因为它不是。）

现在，如果您真的很聪明，则可以在运行查询时以一种可能导致环境崩溃并执行其他操作的方式来表示上面的代码：

query( statement: "select smurfs from some_mushroom", callback: go_do_something_with_result() );

基本上，这就是node.js的工作。您基本上是在进行装饰（由于语言和环境的原因，因此很方便，因此涉及到闭包的要点），因此，您的代码可以使环境对运行的内容和时间有所了解。这样，node.js
在发明异步I / O的意义上并不是 新 的（不是任何人都声称这样的东西），但是在表达方式上却有所不同。

注意：当我说环境可以在何时运行时变得很聪明时，我的意思是说它用来启动一些I / O的线程现在可以用来处理其他请求或可以完成的某些计算并行，或启动其他并行I
/ O。（我不确定节点是否足够成熟，可以为同一请求启动更多工作，但是您明白了。）