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

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

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

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

result = query( "select smurfs from some_mushroom" );// twiddle fingersgo_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。（我不确定节点是否足够成熟，可以为同一请求启动更多工作，但是您明白了。）