Node.js事件循环（Event Loop）和线程池详解

Node的“事件循环”（Event Loop）是它能够处理大并发、高吞吐量的核心。这是最神奇的地方，据此Node.js基本上可以理解成“单线程”，同时还允许在后台处理任意的操作。这篇文章将阐明事件循环是如何工作的，你也可以感受到它的神奇。

事件驱动编程

理解事件循环，首先要理解事件驱动编程（Event Driven Programming）。它出现在1960年。如今，事件驱动编程在UI编程中大量使用。JavaScript的一个主要用途是与DOM交互，所以使用基于事件的API是很自然的。

简单地定义：事件驱动编程通过事件或状态的变化来进行应用程序的流程控制。一般通过事件监听实现，一旦事件被检测到（即状态改变）则调用相应的回调函数。听起来很熟悉？其实这就是Node.js事件循环的基本工作原理。

如果你熟悉客户端JavaScript的开发，想一想那些.on*()方法，如element.onclick()，他们用来与DOM元素相结合，传递用户交互。这个工作模式允许在单个实例上触发多个事件。Node.js通过EventEmitter（事件发生器）触发这种模式，如在服务器端的Socket和 “http”模块中。可以从一个单一实例触发一种或一种以上的状态改变。

另一种常见的模式是表达成功succeed和失败fail。现在一般有两种常见的实现方式。首先是将“Error异常”传入回调，一般作为第一个参数传递给回调函数。第二种即使用Promises设计模式，已经加入了ES6。注* Promise模式采用类似jQuery的函数链式书写方式，以避免深层次的回调函数嵌套，如：

“fs”（filesystem）模块大多采用往回调中传入异常的风格。在技术上触发某些调用，例如fs.readFile()附加事件，但该API只是为了提醒用户，用来表达操作成功或失败。选择这样的API是出于架构的考虑，而非技术的限制。

一个常见的误解是，事件发生器（event emitters）在触发事件时也是天生异步的，但这是不正确的。下面是一个简单的代码片段，以证明这一点。

EventEmitter经常表现地很异步，因为它经常用于通知需要异步完成的操作，但EventEmitter API本身是完全同步的。监听函数内部可以按异步执行，但请注意，所有的监听函数将按被添加的顺序同步执行。

机制概述和线程池

Node本身依赖多个库。其中之一是libuv，神奇的处理异步事件队列和执行的库。

Node利用尽可能多的利用操作系统内核实现现有的功能。像生成响应请求(request)，转发连接(connections)并委托给系统处理。例如，传入的连接通过操作系统进行队列管理，直到它们可以由Node处理。

您可能听说过，Node有一个线程池，你可能会疑惑：“如果Node会按次序处理任务，为什么还需要一个线程池？”这是因为在内核中，不是所有任务都是按异步执行的。在这种情况下，Node.JS必须能在操作时将线程锁定一段时间，以便它可以继续执行事件循环而不会被阻塞。

下面是一个简单的示例图，来表示他内部的运行机制：

            ┌───────────────────────┐
?q──►│         timers                                           │
 │         └───────────┬───────────┘
 │         ┌───────────┴───────────┐
 │         │   pending callbacks                             │
 │         └───────────┬───────────┘          ┌──────────────┐
 │         ┌───────────┴───────────┐          │  incoming:                    │
 │          │          poll                                               │◄──┤ connections,                │
 │         └───────────┬───────────┘          │  data, etc.                     │
 │         ┌───────────┴───────────┐          └──────────────┘
?t───┤      setImmediate                                  │
             └───────────────────────┘

关于事件循环的内部运行机制，有一些理解困难的地方：

所有回调都会经由process.nextTick()，在事件循环（例如，定时器）一个阶段的结束并转换到下一阶段之前预设定。这就会避免潜在的递归调用process.nextTick()，而造成的无限循环。
“Pending callbacks（待回调）”，是回调队列中不会被任何其他事件循环周期处理（例如，传递给fs.write）的回调。

Event Emitter 和 Event Loop

通过创建EventEmitter，可简化与事件循环的交互。它是一个通用的封装，可以让你更容易地创建基于事件的API。关于这两者如何互动往往让开发者感到混乱。

下面的例子表明，忘记了事件是同步触发的，可能导致事件被错过。

上面的'thing1'事件，永远不会被MyThing()捕获，因为MyThing()必须在实例化后才能侦听事件。下面的是一个简单的解决方法，不必添加任何额外的闭包：

下面的方案也可以工作，不过要损失一些性能：

另一个问题是触发Error(异常)。找出您应用程序中的问题已经很难了，但没了调用堆栈（注* e.stack），则几乎不可能调试。当Error被远端的异步请求调用堆栈将丢失。有两个可行的解决方案：同步触发或确保Error跟其他重要信息一起传入。下面的例子演示了这两种解决方案：

审时度势。当error被触发时，是有可能被立即处理的。或者，它可能是一些琐碎的，可以很容易处理，或在以后再处理的异常。此外通过一个构造函数，传递Error也不是一个好主意，因为构造出来的对象实例很有可能是不完整的。刚才直接抛出Error的情况是个例外。

结束语

这篇文章比较浅显地探讨了有关事件循环的内部运作机制和技术细节。都是经过深思熟虑的。另一篇文章会讨论事件循环与系统内核的交互，并展现NodeJS异步运行的魔力。