这篇文章是写给谁的?

这篇文章是针对在客户端或服务器端使用或计划使用JavaScript的web开发人员的。如果你已经精通事件循环，那么这篇文章的大部分对你来说会很熟悉。对于那些还不是很精通的人，我希望能给你提供一个基本的了解，这样可以更好地帮助你阅读和编写日常代码。

非阻塞I / O

在JavaScript中，几乎所有的I/O都是非阻塞的。这包括HTTP请求，数据库操作和磁盘读写，单线程执行要求在运行期执行一个操作时，提供一个回调函数，然后继续做其它的事情。当操作已经完成时，消息和已提供的回调函数一起插入到队列。在将来的某个时候，消息从队列移除，回调函数触发。

虽然这种交互模型可能对已经习惯使用用户界面的开发人员很熟悉，比如“mousedown,”和“click”事件在某一时刻被触发。这与通常在服务器端应用程序进行的同步式请求-响应模型是不同的。

让我们来比较一下两小块代码，发出HTTP请求到www.google.com和输出响应到控制台。首先看看Ruby，配合使用Faraday（一个Ruby 的HTTP 客户端开发库）:

执行路径很容易跟踪:

1、执行get方法，执行的线程等待，直到收到响应
2、从谷歌收到响应并返回给调用者，它存储在一个变量中
3、变量的值(在本例中，就是我们的响应)输出到控制台
4、值“Done!“输出到控制台
让我们使用Node.js和Request库在JavaScript做同样的事情:

表面上看略有不同,实际行为截然不同:

1、执行请求函数，传递一个匿名函数作为回调，当响应在将来某个时候可用时执行回调。
2、“Done!“立即输出到控制台
3、在将来的某个时候，响应返回和回调执行时，输出它的内容到控制台
事件循环

将调用者和响应解耦，使得JavaScript在运行期等待异步操作完成和回调触发时可以做其他事情。但是这些回调在内存中是如何组织的，按什么顺序执行？什么导致他们被调用？

JavaScript运行时包含一个消息队列，它存储了需要处理的消息的列表和相关的回调函数。这些消息是以队列的形式来响应回调函数所涉及的外部事件(如鼠标单击或收到HTTP请求的响应)的。例如，如果用户单击一个按钮，但没有提供回调函数，那么也没有消息会被加入队列。

在一次循环，队列提取下一条消息(每次提取称为一次“tick”)，当事件发生，该消息的回调执行。

回调函数的调用在调用栈作为初始化frame(片段)，由于JavaScript是单线程的，未来的消息提取和处理因为等待栈的所有调用返回而被停止。后续(同步)函数调用会添加新的调用frame到栈(例如，函数init调用函数changeColor)。

在这个例子中，当用户单击“foo”元素时，一条消息(及其回调函数changeColor)会被插入到队列，并触发“onclick“事件。当消息离开队列时，其回调函数changeColor被调用。当changeColor返回(或者是抛出一个错误)，事件循环仍在继续。只要函数changeColor存在，并指定为“foo”元素的onclick方法的回调，那么在该元素上单击会导致更多的消息(和相关的回调changeColor)插入队列。

队列附加消息

如果一个函数在代码中按异步调用(比如setTimeout)，提供的回调将最终作为一个不同的消息队列的一部分被执行，它将发生在事件循环的某个未来的动作上。例如:

由于setTimeout的非阻塞特性，它的回调将在至少0毫秒后触发，而不是作为消息的一部分被处理。在这个示例中，setTimeout被调用， 传入了一个回调函数g且延时0毫秒后执行。当我们指定时间到达(当前情况是，几乎立即执行)，一个单独的消息将被加入队列（g作为回调函数）。控制台打印的结果会是像这样：“foo”，“baz”，“blix”，然后是事件循环的下一个动作:“bar”。如果在同一个调用片段中，两个调用都设置为setTimeout -传递给第二个参数的值也相同-则它们的回调将按照调用顺序插入队列。

Web Workers

使用Web Workers允许您能够将一项费时的操作在一个单独的线程中执行，从而可以释放主线程去做别的事情。worker（工作线程）包括一个的消息队列，事件循 环，内存空间于实例化它的原始线程。worker和主线程之间的通信通过消息传递，看起来很像我们往常常见的传统事件代码示例。

首先，我们的worker:

然后，主要的代码块在我们的HTML中以script-标签存在：