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的函数链式书写方式,以避免深层次的回调函数嵌套,如:

复制代码 代码如下:


$.getJSON('/getUser').done(successHandler).fail(failHandler)

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

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

复制代码 代码如下:


function MyEmitter() {
  EventEmitter.call(this);
}
util.inherits(MyEmitter, EventEmitter);

MyEmitter.prototype.doStuff = function doStuff() {
  console.log('before')
  emitter.emit('fire')
  console.log('after')}
};

var me = new MyEmitter();
me.on('fire', function() {
  console.log('emit fired');
});

me.doStuff();
// 输出:
// before
// emit fired
// after

注* 如果 emitter.emit 是异步的,则输出应该为
// before
// after
// emit fired


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

机制概述和线程池

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

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

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

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


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

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

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wgfpdp.html