当 Node.js 在内部仍然依赖线程时，它如何本质上更快? [英] How is Node.js inherently faster when it still relies on Threads internally?

问题描述

我刚刚看了以下视频:Node.js 简介 仍然不明白你是如何获得速度优势的.

I just watched the following video: Introduction to Node.js and still don't understand how you get the speed benefits.

主要是，Ryan Dahl(Node.js 的创建者)曾说过 Node.js 是基于事件循环而不是基于线程的.线程很昂贵，只能留给并发编程专家使用.

Mainly, at one point Ryan Dahl (Node.js' creator) says that Node.js is event-loop based instead of thread-based. Threads are expensive and should only be left to the experts of concurrent programming to be utilized.

随后，他展示了 Node.js 的架构栈，它有一个底层的 C 实现，内部有自己的线程池.所以很明显，Node.js 开发人员永远不会启动他们自己的线程或直接使用线程池……他们使用异步回调.明白了这么多.

Later, he then shows the architecture stack of Node.js which has an underlying C implementation which has its own Thread pool internally. So obviously Node.js developers would never kick off their own threads or use the thread pool directly...they use async call-backs. That much I understand.

我不明白的是，Node.js 仍然在使用线程......它只是隐藏了实现，所以如果 50 人请求 50 个文件(当前不在内存中)那么这会更快，然后不是需要 50 个线程?

What I don't understand is the point that Node.js still is using threads...it's just hiding the implementation so how is this faster if 50 people request 50 files (not currently in memory) well then aren't 50 threads required?

唯一的区别在于，由于它是在内部管理的，Node.js 开发人员不必编写线程化的细节，但在底层它仍然使用线程来处理 IO(阻塞)文件请求.

The only difference being that since it's managed internally the Node.js developer doesn't have to code the threaded details but underneath it's still using the threads to process the IO (blocking) file requests.

所以你真的不只是解决一个问题(线程)并在该问题仍然存在的时候隐藏它:主要是多线程、上下文切换、死锁……等等?

So aren't you really just taking one problem (threading) and hiding it while that problem still exists: mainly multiple threads, context switching, dead-locks...etc?

这里一定有一些细节我还是不明白.

There must be some detail I still do not understand here.

推荐答案

实际上这里混杂了一些不同的东西.但它始于线程真的很难的模因.因此，如果它们很难，您更有可能在使用线程时 1) 由于错误而中断和 2) 没有尽可能有效地使用它们.(2) 就是你要问的那个.

There are actually a few different things being conflated here. But it starts with the meme that threads are just really hard. So if they're hard, you are more likely, when using threads to 1) break due to bugs and 2) not use them as efficiently as possible. (2) is the one you're asking about.

想想他给出的一个例子，一个请求进来，你运行一些查询，然后对结果做一些事情.如果您以标准程序方式编写它，代码可能如下所示:

Think about one of the examples he gives, where a request comes in and you run some query, and then do something with the results of that. If you write it in a standard procedural way, the code might look like this:

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

如果传入的请求导致您创建一个运行上述代码的新线程，那么您将有一个线程坐在那里，在 query() 运行期间什么都不做.(根据 Ryan 的说法，Apache 使用单个线程来满足原始请求，而 nginx 在他所说的情况下表现优于它，因为它不是.)

If the request coming in caused you to create a new thread that ran the above code, you'll have a thread sitting there, doing nothing at all while while query() is running. (Apache, according to Ryan, is using a single thread to satisfy the original request whereas nginx is outperforming it in the cases he's talking about because it's not.)

现在，如果你真的很聪明，你会用一种方式来表达上面的代码，当你运行查询时，环境可以停止并做其他事情:

Now, if you were really clever, you would express the code above in a way where the environment could go off and do something else while you're running the query:

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

这基本上就是 node.js 正在做的事情.你基本上是在装饰——以一种方便的方式，因为语言和环境，因此是关于闭包的要点——你的代码使环境可以聪明地知道什么运行，什么时候运行.那样的话，node.js 并不是新，因为它发明了异步 I/O(并不是说有人声称这样的东西)，但它是新的，因为它的表达方式有点不同的.

This is basically what node.js is doing. You're basically decorating -- in a way that is convenient because of the language and environment, hence the points about closures -- your code in such a way that the environment can be clever about what runs, and when. In that way, node.js isn't new in the sense that it invented asynchronous I/O (not that anyone claimed anything like this), but it's new in that the way it's expressed is a little different.

注意:当我说环境可以聪明地决定什么运行以及何时运行时，具体来说我的意思是它用于启动某些 I/O 的线程现在可以用于处理某些其他请求，或某些计算可以并行完成，也可以启动其他一些并行 I/O.(我不确定节点是否复杂到可以为相同的请求开始更多的工作，但你明白了.)

Note: when I say that the environment can be clever about what runs and when, specifically what I mean is that the thread it used to start some I/O can now be used to handle some other request, or some computation that can be done in parallel, or start some other parallel I/O. (I'm not certain node is sophisticated enough to start more work for the same request, but you get the idea.)

这篇关于当 Node.js 在内部仍然依赖线程时，它如何本质上更快?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！