理解 node.js 的事件循环

node.js 的第一个基本观点是，I/O 操做是昂贵的：

 

目前的编程技术最大的浪费来自等待 I/O 操做的完成。有几种方法能够解决这些对性能的影响（来自 Sam Rushing）：
　　同步：依次处理单个请求。
　　　　优势：简单。
　　　　缺点：任何一个请求都会阻塞其他请求。
　　建立新进程：为每一个请求建立一个进程处理
　　　　优势：容易。
　　　　缺点：扩展性很差，数百个链接意味着数百个进程。fork()是 Unix 程序员的锤子。由于它颇有用，全部的问题都像是钉子。但这一般是多余的。
　　线程：为每一个请求建立一个线程处理。
　　　　优势：容易；因为线程的开销一般都很小，相比于使用 fork 对内核更友好。
　　　　缺点：你的机器可能没有线程，而且线程编程很容易变得复杂，也存在如何访问共享资源的问题。

第二个基本观点是，单线程链接很是消耗内存。

Apach 是多线程的：为每个请求建立一个线程（或者进程，这取决于配置）。你能够看到增长当前链接数是如何消耗内存的，多个线程须要同时服务多个客户。Nginx 和 Node.js 不是多线程的，由于多线程和多进程会带来沉重的内存开销。它们是单线程的，可是基于事件的。经过单线程处理多个链接，解决数千个线程/进程的开销问题。

Node.js 为代码保持着单线程的运行环境

Node.js 确实是单线程运行的：你不能执行任何并发代码；例如“sleep”，这会使服务器中止。

 

当代码运行时，node.js不会响应客户端的其余请求，由于它只有一个线程在执行代码。或者你可使用一些 CPU-密集型代码，例如，调整图片尺寸，这仍然会阻塞其余请求。

 然而，一切代码都能并行执行

并无办法让代码在单线程中并行运行。除了全部的 I/O 操做和异步事件，如下代码并不会阻塞服务器：[codesyntax lang="javascript"]

 

在一个请求中执行以上代码，数据库在休眠时其余请求也能被很好的处理。

这样有什么好处？咱们何时应该将同步改成异步/并行执行？

同步执行是好方法，由于这使代码编写变得简单（与多线程相比，并发问题致使了 WTFs）。

在 node.js 中，你不须要担忧后台会发生什么：只须要使用回调执行 I/O 操做；这保证了你的代码不会被中断，同时 I/O 操做不会阻塞其余请求，每一个请求也不会增长线程/进程的开销（例如，Apache 中的内存开销）。

异步 I/O 操做也是好方法，由于 I/O 操做相较于大多数代码的执行更昂贵，咱们应该作其余的事情，而不是等待 I/O 操做

 

时间循环是“一个可以加工和处理外部事件并将它们转换为回调调用的实体”。所以 I/O 调用的关键在于 Node.js 可以从一个请求切换到另外一个请求。在一个 I/O 调用中，代码会保存回调函数，并将控制权返回给 node.js 的运行时环境。当数据可用时回调函数将被调用。

固然，在后台中，有用于数据库访问和执行进程的线程和进程。然而，这并无使代码暴露，所以你不须要为 I/O 操做担忧，例如，数据库或者其余进程对于每个请求都是异步的，这些线程的执行结果会经过事件循环返回给代码。与 Apache 模式相比，不须要为每一个链接提供单个线程，所以须要更少的线程和线程开销；只有当真的须要并行运行时，即便管理权在 Node.js 也可以运行。

除了 I/O 操做的调用，Node.js 但愿其余的全部请求都能迅速响应；例如：CPU-密集型工做应该被拆分到交互事件的进程中，或者像 WebWorkers 那样抽象的使用。（显然地）这意味着在后台没有其余的线程并发运行交互事件。基本上，全部的监听事件对象（都是　EventEmitter 的实例）都支持异步交互事件，你可以以这种方式与阻塞代码交互，例如使用 files，sockets 或者子进程，这些在 Node.js 中都是 EventEmitters。[多核][8]也可使用这种方法，请参见：node-http-proxy

内部实现

在内部，node.js 依赖于 libev 实现事件循环，以 libeio 为辅助，使用混合线程实现异步 I/O 操做。要想学习更多，就须要查看 libev 的文档。

如何在 Node.js 中使用异步？

Tim Caswell 在他出色的演讲中描述了这种模式：

　　First-class 函数。例如，咱们将函数做为参数传递，在须要的时候执行他们。
　　Function 形式。也被称做匿名函数或者闭包函数，当 I/0 操做完成后执行。

 

原文：Understanding the node.js event loop