我正在尝试了解 JavaScript 运行时如何使用其单线程模型。有一个事件循环将阻塞操作(其中大部分是 I/O)移动到运行时的不同部分，以保持主线程的清洁。顺便说一句，我发现这个模型非常有创意。
我认为这个模型自创建以来就是 JavaScript 的一部分，并且大多数阻塞 I/O 操作(如 AJAX 调用)大约在 5 年后才“被发现”，那么一开始单线程的动机是什么非阻塞模型，如果几乎没有阻塞操作，并且该语言仅用于验证表单和动画屏幕。是长远的眼光还是运气？
最佳答案
正如您已经说过的，事件循环用于处理缓慢的 I/O - 或者更一般地说，处理不涉及 CPU 的操作，这些操作发生在代码运行的其他地方，需要此类操作的结果 .
但 I/O 不仅仅是网络和磁盘! I/O 比任何设备都慢得多:计算机与人类通信!
GUI 输入——点击按钮、输入文本，都是 SLOOOOOWW，因为计算机等待用户输入。您的代码需要来自外部源的数据(代码运行所在的外部 CPU)。
GUI 事件是基于事件编程的主要原因。想一想:您将如何同步进行 GUI 编程？ (您可以使用操作系统抢占 - 如下所述)您不知道用户何时会单击按钮。基于事件的编程是这个特定任务的最佳选择(我们知道)。
此外，一个要求是只有一个线程，因为并行编程是困难的，而 Javascript 是为“普通用户”准备的。
这是我刚找到的一篇不错的博文:
http://www.lanedo.com/the-main-loop-the-engine-of-a-gui-library/
Modern GUI libraries have in common that they all embody the Event-based Programming paradigm. These libraries implement GUI elements that draw output to a computer screen and change state in response to incoming events. Events are generated from different sources. The majority of events are typically generated directly from user input, such as mouse movements and keyboard input. Other events are generated by the windowing system, for instance requests to redraw a certain area of a GUI, indications that a window has changed size or notifications of changes to the session’s clipboard. Note that some of these events are generated indirectly by user input.
我想补充一点:
我们有两个主要选项来处理您的代码必须等待外部事件的问题(即无法在您的代码运行的 CPU 中计算或从直接连接的 RAM 检索的数据 - 任何会留下CPU 无法继续处理您的代码):
- 事件
- Preemption通过像操作系统这样的“更强大的力量”。
在后一种情况下，您可以编写顺序代码，操作系统将检测您的代码何时需要尚不存在的数据。它会停止执行您的代码，并将 CPU 交给其他代码。
从某种意义上说，Javascript 中无处不在的基于事件的范式是一种倒退:与仅按顺序写下您想要的内容并让操作系统负责管理资源相比，为所有内容编写大量事件处理程序是一项大量工作“中央处理器”。
我注意到，当我的基于事件的编程是针对 GUI 时，我从来不想提示——但是当我不得不为磁盘和网络 I/O 做这件事时，我突然意识到所有事件处理需要付出多少努力与让操作系统在后台处理相比。
我的理论:在事件处理程序中应对人类(他们的行为)感觉自然，毕竟这是软件(基于 GUI 的软件)的全部目的。但是，当我不得不为设备 做所有基于事件的事情时，感觉很不自然——我必须在我的编程中适应硬件？
从某种意义上说，出现在我们面前的基于事件的编程是从以前的“第四代语言”梦想中迈出的一步，回到更多面向硬件的编程——为了机器效率，而不是程序员效率。习惯编写基于事件的代码需要很多时间。同步编写并让操作系统负责资源管理实际上更容易 - 除非您已经习惯了基于事件的代码，以至于您现在对其他任何事情都有下意识的 react 。
但想一想:在基于事件的编程中，我们让物理细节(例如我们的代码在何处执行以及从何处获取数据)决定我们如何编写代码。我们不是专注于我们想要什么，而是更多地关注如何我们希望它完成。这是从抽象到硬件的一大步。
我们现在正在慢慢开发和引入可以帮助我们解决这个问题的工具，但即使像 promises 这样的事情仍然需要我们考虑“基于事件”——我们在有事件的地方使用这样的结构，即我们必须意识到休息。所以我看不出有多大收获，因为我们仍然必须以不同的方式编写具有此类“中断”(即离开 CPU)的代码。
关于javascript - 为什么在几乎没有阻塞操作的情况下，事件循环从 JavaScript 开始就存在，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29575191/