我是 Node 的新手，并尝试了解 node 的非阻塞性质。
在下图中，我创建了请求的高级图表。
据我了解，来自单个用户的单个应用程序的所有进程都在单个线程上运行。
我想了解的是事件循环的逻辑如何适合这个图表。事件循环是否与指令排队的处理器管道相同？
想象一下，我们将一个应用页面加载到 RAM 中，该页面创建一个流以供程序读取：
readstream.on('data', function(data) {});
创建读取流和等待数据发生的指令：该指令是否“挂起”在处理器的寄存器中（等待 I/O 完成），而在多线程环境中，处理器只是不接受新指令直到前一个 I/O 请求的结果返回到 RAM 为止？
还是我认为这完全/部分错误的方式？
只是一个补充（相关的，也许是愚蠢的）问题：在服务器上的不同线程上运行不同的用户，单线程的好处不是只对单个用户有用吗？
我对这种类型的细节不熟悉，所以如果这个问题对你不完全有意义，请原谅。但在继续前进之前，理解这一点对我来说似乎是必不可少的。
事件驱动的非阻塞 I/O 依赖于现代操作系统具有在 O/S 级别执行轮询（不浪费 CPU 周期）的“选择”方法这一事实。select 方法允许您为某些 I/O 事件注册回调。这往往比启用线程的语言中常用的“每个连接线程”模型更有效。有关更多信息，请在 Unix/Linux 操作系统上执行“人工选择”。
线程和 I/O 与操作系统实现和服务有关，而不是 CPU 架构。
涉及任何类型的输入/输出设备（大容量存储、网络、串行端口等）的操作被构造为从 CPU 到外部设备的请求，这些请求通过几种可能的机制之一在以后得到满足。
在这个现实之上，操作系统提供了替代的编程模型。在一个模型中，输入/输出操作的实际性质本质上是伪装的，因此执行程序被赋予一个看起来是同步的 API。在 C 程序中，对write()系统调用的调用将导致整个进程延迟，直到操作完成。
另一种编程模型更接近地暴露了系统的异步现实。这就是 Node 使用的。操作系统提供了启动长时间异步操作的方法，以及进程检查结果或阻塞并等待结果的方法。在 Node 中，运行时系统可以处理许多单独的操作，因为整个模型基于响应事件而运行的代码。事件可以是合成的事物（例如最初加载和运行的 Node 模块的“事件”），也可以是实际异步外部事件的结果。在输入/输出操作的情况下，Node 运行时等待操作系统通知并将其转换为导致某些 JavaScript 代码运行的事件。