当 Node.js 在内部仍然依赖于 Threads 时，它如何天生就更快？

Posted 2023-02-14

【中文标题】当 Node.js 在内部仍然依赖于 Threads 时，它如何天生就更快？

【英文标题】：How is Node.js inherently faster when it still relies on Threads internally?

【发布时间】：2011-04-07 11:38:26

【问题描述】：

我刚刚观看了以下视频：Introduction to Node.js，但仍然不明白您如何获得速度优势。

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

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

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

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

所以你不是真的只是解决一个问题（线程）并在问题仍然存在时隐藏它：主要是多线程、上下文切换、死锁......等等？

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

【问题讨论】：

我倾向于同意你的说法，即这种说法有些过于简单化了。我认为node的性能优势归结为两点：1）实际线程都包含在相当低的级别，因此在大小和数量上仍然受到限制，从而简化了线程同步； 2) 通过select() 进行的操作系统级“切换”比线程上下文交换更快。

请看***.com/questions/24796334/…

【参考方案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。 （我不确定节点是否足够复杂，可以为同一个请求启动更多工作，但你明白了。）

【讨论】：

好的，我绝对可以看到这如何提高性能，因为在我看来，您可以最大限度地利用您的 CPU，因为没有任何线程或执行堆栈只是在等待 IO 返回因此，Ryan 所做的实际上是找到了一种弥补所有差距的方法。

是的，我要说的一件事是，他并没有找到缩小差距的方法：这不是一种新模式。不同的是，他使用 javascript 让程序员以一种更方便这种异步的方式来表达他们的程序。可能是一个挑剔的细节，但仍然......

还值得指出的是，对于许多 I/O 任务，Node 使用任何可用的内核级异步 I/O api（epoll、kqueue、/dev/poll 等）

我仍然不确定我是否完全理解它。如果我们认为在 Web 请求中 IO 操作是处理请求所需的大部分时间，并且如果为每个 IO 操作创建一个新线程，那么对于 50 个快速连续的请求，我们将可能有 50 个线程并行运行并执行它们的 IO 部分。与标准 Web 服务器的不同之处在于，整个请求都在线程上执行，而在 node.js 中只是其 IO 部分，但这是占用大部分时间并使线程等待的部分。跨度>

@SystemParadox 感谢您指出这一点。实际上，我最近对该主题进行了一些研究，实际上，当在内核级别正确实现异步 I/O 时，在执行异步 I/O 操作时不使用线程。相反，一旦 I/O 操作开始，调用线程就会被释放，当 I/O 操作完成并且有线程可用时，会执行回调。因此，如果正确实现了对 I/O 操作的异步支持，node.js 可以（几乎）使用一个线程并行运行 50 个并发请求和 50 个 I/O 操作。

【参考方案2】：

注意！这是一个旧答案。虽然在粗略的轮廓上仍然如此，但由于 Node 在过去几年的快速发展，一些细节可能已经发生了变化。

它使用线程是因为：

O_NONBLOCK option of open() does not work on files。 有些第三方库不提供非阻塞 IO。

要伪造非阻塞 IO，线程是必需的：在单独的线程中进行阻塞 IO。这是一个丑陋的解决方案，并且会导致大量开销。

在硬件层面上更糟糕：

使用DMA CPU 异步卸载 IO。 数据直接在 IO 设备和内存之间传输。 内核将其包装在一个同步的阻塞系统调用中。 Node.js 将阻塞系统调用封装在一个线程中。

这简直是愚蠢和低效的。但它至少有效！我们可以享受 Node.js，因为它在事件驱动的异步架构背后隐藏了丑陋和繁琐的细节。

也许将来有人会为文件实现 O_NONBLOCK？...

编辑：我和一个朋友讨论过这个问题，他告诉我，线程的替代方法是使用 select 进行轮询：指定超时 0 并对返回的文件描述符执行 IO（现在他们保证不会阻止）。

【讨论】：

Windows 怎么样？

抱歉，不知道。我只知道 libuv 是做异步工作的平台中立层。在 Node 开始时没有 libuv。然后决定分离 libuv，这使得特定于平台的代码更容易。换句话说，Windows 有它自己的异步故事，这可能与 Linux 完全不同，但对我们来说这并不重要，因为 libuv 为我们做了艰苦的工作。

【参考方案3】：

我担心我在这里“做错了事”，如果是这样，请删除我并道歉。特别是，我看不到我是如何创建一些人创建的整洁的小注释的。但是，我对此线程有很多担忧/意见。

1) 流行答案之一的伪代码中的注释元素

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

本质上是假的。如果线程正在计算，那么它不是在转动拇指，而是在做必要的工作。另一方面，如果它只是在等待 IO 完成，那么它不使用 CPU 时间，内核中线程控制基础设施的全部意义在于 CPU 会找到一些有用的东西做。按照这里的建议，“摆弄你的拇指”的唯一方法是创建一个轮询循环，没有人编写过真正的网络服务器的代码不足以做到这一点。

2) “线程很难”，仅在数据共享的上下文中才有意义。如果您有本质上独立的线程，例如处理独立 Web 请求时的情况，那么线程非常简单，您只需编写如何处理一项作业的线性流程，并且知道它将处理多个请求，并且每个将有效地独立。就个人而言，我敢冒险，对于大多数程序员来说，学习闭包/回调机制比简单地编写从上到下的线程版本更复杂。 （但是，是的，如果你必须在线程之间进行通信，生活会变得非常艰难，但我不相信闭包/回调机制真的改变了这一点，它只是限制了你的选择，因为这种方法仍然可以通过线程实现. 无论如何，这完全是其他讨论，与这里无关）。

3) 到目前为止，没有人提供任何真正的证据来说明为什么一种特定类型的上下文切换会比任何其他类型更耗时或更短。我在创建多任务内核（针对嵌入式控制器的小规模，没有什么比“真正的”操作系统更花哨）方面的经验表明，情况并非如此。

4) 迄今为止，我所看到的所有旨在显示 Node 比其他网络服务器快得多的插图都存在可怕的缺陷，但是，它们的缺陷在某种程度上确实间接说明了我肯定会接受的一个优势节点（它绝不是微不足道的）。 Node 看起来不需要（实际上甚至也不允许）调整。如果您有线程模型，则需要创建足够的线程来处理预期负载。做得不好，你最终会表现不佳。如果线程太少，那么CPU是空闲的，但是无法接受更多的请求，创建的线程太多，会浪费内核内存，在Java环境下，也会浪费主堆内存.现在，对于 Java，浪费堆是破坏系统性能的第一个，最好的方法，因为高效的垃圾收集（目前，这可能会随着 G1 而改变，但截至 2013 年初，陪审团似乎仍在这一点上至少）取决于有很多备用堆。所以，问题来了，用太少的线程调整它，你有空闲的 CPU 和很差的吞吐量，用太多的调整它，它会以其他方式陷入困境。

5) 还有另一种方式可以让我接受 Node 的方法“在设计上更快”这一说法的逻辑，就是这样。大多数线程模型使用时间片上下文切换模型，分层在更合适（价值判断警报：）和更有效（不是价值判断）的抢占模型之上。发生这种情况有两个原因，首先，大多数程序员似乎不了解优先级抢占，其次，如果您在 windows 环境中学习线程，无论您喜欢与否，时间片都在那里（当然，这强化了第一点; 值得注意的是，Java 的第一个版本在 Solaris 实现中使用了优先级抢占，在 Windows 中使用了时间片。因为大多数程序员不理解并抱怨“线程在 Solaris 中不起作用”，所以他们将模型改为时间片）。无论如何，底线是时间片会创建额外的（并且可能是不必要的）上下文切换。每次上下文切换都会占用 CPU 时间，而该时间实际上已从可以在手头的实际工作中完成的工作中移除。但是，由于时间片在上下文切换上所花费的时间不应超过总时间的一小部分，除非发生了一些非常奇怪的事情，而且我没有理由期望在简单的网络服务器）。所以，是的，时间切片中涉及的过多上下文切换效率低下（并且这些通常不会发生在 kernel 线程中，顺便说一句），但差异将是吞吐量的几个百分点，而不是那种Node 性能声明中隐含的整数因子。

无论如何，抱歉，这一切冗长而漫不经心，但我真的觉得到目前为止，讨论还没有证明任何事情，我很高兴听到有人在这两种情况下的消息：

a) 真正解释了为什么 Node 应该更好（除了我上面概述的两种情况，我相信第一种情况（调整不佳）是迄今为止我所看到的所有测试的真正解释。 （[编辑]，实际上，我想得越多，我就越想知道大量堆栈使用的内存在这里是否很重要。现代线程的默认堆栈大小往往非常大，但是内存由基于闭包的事件系统分配的只是需要的）

b) 一个真正的基准测试，它实际上为选择的线程服务器提供了公平的机会。至少这样，我不得不停止相信这些说法本质上是错误的；>（[编辑]这可能比我预期的要强，但我确实觉得对性能优势的解释充其量是不完整的，而且显示的基准是不合理的）。

干杯， 托比

【讨论】：

线程问题：它们需要 RAM。一个非常繁忙的服务器可以运行多达几千个线程。 Node.js 避免了线程，因此效率更高。效率不是通过更快地运行代码来实现的。代码是在线程中运行还是在事件循环中运行并不重要。对于 CPU 来说也是一样的。但是通过取消线程，我们节省了 RAM：只有一个堆栈而不是几千个堆栈。我们还保存了上下文切换。

但是节点并没有取消线程。它仍然在内部将它们用于 IO 任务，这是大多数 Web 请求所需要的。

节点也将回调的闭包存储在 RAM 中，所以我看不到它在哪里获胜。

@levi 但是 nodejs 不使用“每个请求一个线程”之类的东西。它使用 IO 线程池，可能是为了避免使用异步 IO API 的复杂性（也许 POSIX open() 不能设为非阻塞？）。这样，它可以摊销传统 fork()/pthread_create()-on-request 模型必须创建和销毁线程的任何性能损失。而且，如后记 a) 中所述，这也摊销了堆栈空间问题。您可能可以使用 16 个 IO 线程来处理数千个请求。

“现代线程的默认堆栈大小往往相当大，但基于闭包的事件系统分配的内存只是需要的” 我得到的印象这些应该是相同的顺序。闭包并不便宜，运行时必须将单线程应用程序的整个调用树保留在内存中（可以说是“模拟堆栈”），并且当树的叶子作为关联的闭包被释放时能够进行清理得到“解决”。这将包括大量对无法进行垃圾收集并且会在清理时影响性能的堆上内容的引用。

【参考方案4】：

我不明白的是重点 Node.js 仍在使用线程。

Ryan 对阻塞的部分使用线程（大多数 node.js 使用非阻塞 IO），因为有些部分非常难以编写非阻塞。但我相信 Ryan 的愿望是让一切都没有阻塞。 在slide 63(internal design) 上，您会看到Ryan 使用libev（抽象异步事件通知的库）作为非阻塞eventloop。由于事件循环 node.js 需要较少的线程，从而减少了上下文切换、内存消耗等。

【参考方案5】：

线程仅用于处理没有异步功能的函数，例如stat()。

stat() 函数总是阻塞的，所以 node.js 需要使用一个线程来执行实际的调用而不阻塞主线程（事件循环）。如果您不需要调用此类函数，则可能不会使用线程池中的任何线程。

【参考方案6】：

我对 node.js 的内部工作原理一无所知，但我可以看到使用事件循环如何胜过线程 I/O 处理。想象一个磁盘请求，给我 staticFile.x，为该文件创建 100 个请求。每个请求通常占用一个线程来检索该文件，即 100 个线程。

现在想象第一个请求创建一个成为发布者对象的线程，所有其他 99 个请求首先查看是否有 staticFile.x 的发布者对象，如果有，则在它工作时监听它，否则启动一个新线程因此是一个新的发布者对象。

一旦单线程完成，它会将 staticFile.x 传递给所有 100 个侦听器并自行销毁，因此下一个请求会创建一个全新的线程和发布者对象。

所以在上面的例子中是 100 个线程与 1 个线程，但也是 1 个磁盘查找而不是 100 个磁盘查找，增益可能相当惊人。瑞恩是个聪明人！

另一种看待方式是他在电影开头的一个例子。而不是：

pseudo code:
result = query('select * from ...');

同样，对数据库的 100 次单独查询与...：

pseudo code:
query('select * from ...', function(result)
    // do stuff with result
);

如果一个查询已经在进行，其他相同的查询将简单地加入潮流，因此您可以在一次数据库往返中进行 100 个查询。

【讨论】：

数据库的事情更多的是一个不等待答案同时阻止其他请求（可能会或可能不会使用数据库）的问题，而是要求一些东西，然后让它在它调用你的时候回来。我不认为它将它们联系在一起，因为这很难跟踪响应。此外，我认为没有任何 mysql 接口可以让您在一个连接上保存多个无缓冲响应 (??)

这只是一个抽象的例子来解释事件循环如何提供更高的效率，nodejs 在没有额外模块的情况下对 DB 无能为力;)

是的，我的评论更多的是针对单个数据库往返中的 100 个查询。 :p

嗨 BGerrissen：好帖子。那么，当一个查询正在执行时，其他类似的查询会像上面的 staticFile.X 示例一样“监听”吗？例如，100 个用户检索相同的查询，只有一个查询将被执行，其他 99 个将听第一个？谢谢！

你让它听起来像 nodejs 自动记忆函数调用或其他东西。现在，由于您不必担心 JavaScript 事件循环模型中的共享内存同步，因此更容易安全地将内容缓存在内存中。但这并不意味着 nodejs 会神奇地为您做到这一点，或者这就是被问及的性能增强类型。

【参考方案7】：

Node.JS 并不快（也不意味着它更慢），但 在处理单线程方面效率很高，与处理其单线程的阻塞多线程系统相比！

我已经制作了图表来类比解释这个陈述。

现在当然可以在阻塞的多线程系统（这就是 Node.js 的底层）之上构建一个非阻塞系统，但它非常复杂。而且您必须在需要非阻塞代码的地方执行此操作。

Javascript 生态系统（如 nodejs）提供开箱即用的语法。 JS 语言 sytanx 在需要时提供了所有这些功能。此外，作为其语法的一部分，代码的读者会立即知道代码在哪里是阻塞的，在哪里是非阻塞的。

---

多线程阻塞系统的阻塞部分使其效率降低。被阻塞的线程在等待响应期间不能用于其他任何事情。

虽然非阻塞单线程系统充分利用其单线程系统。