nodejs事件循环机制

nodejs是基于v8引擎的JavaScript运行时。（注意nodejs不是一门新的编程语言）

nodejs是基于libuv实现 异步非阻塞式i/o 操作的。而事件循环是nodejs处理非阻塞式I/O操作的机制。

以下是我理解的nodejs事件循环机制，如有问题，欢迎指正。

首先node10+的事件循环机制与浏览器端js的事件循环机制基本一致。

单线程or多线程

1、nodejs的主线程是单线程，那单线程如何完成异步操作呢？

基于底层c++ libuv库来实现。js通过V8引擎调用node API，node API底层由c++ libuv库实现，libuv库将接收到的不同异步操作分配给不同的线程，不同线程处理结束后已异步方式，将结果返回给v8引擎。

js任务分为同步任务和异步任务，异步任务分为微任务与宏任务。

正常js执行顺序为，执行栈中同步任务执行完毕，则执行全部微任务（清空微任务），此时主线程空闲，则执行***一次***宏任务（事件队列），继续执行执行栈，微任务队列，再执行一次宏任务。。依此反复。

1、主线程执行栈全部任务执行完毕。
2、检查微任务队列，process.nextTick优先级最高，总是最先执行。
3、检查宏任务队列，提取一次任务推入执行栈，进行执行。

2、宏任务包含 setTimeout i/o setImmediate等等这么多，如果后台都已操作完成，优先执行哪一个回调呢？

这才是事件循环的关键，特指上图右侧宏任务队列。事件循环就是为了解决异步操作。所以同步任务不属于事件循环，同时微任务也不属于事件循环的一部分。

事件循环如图分为6个阶段，每个阶段为一个FIFO回调队列（可理解为回调函数数组），按图顺序依次执行。事件循环每进入一个阶段，则将该阶段的回调队列用尽（全部执行完毕）或到最大限制回调数，则进入下一阶段。

举个栗子

//宏任务 check阶段 暂时命名任务1
setImmediate(()=>{
	console.log(1)
});
//宏任务 timer阶段   暂时命名任务2
setTimeout(()=>{
    console.log(2);
    //宏任务 timer阶段 暂时命名任务22
	setTimeout(()=>{
		console.log(22);
	},0);
},0);
//宏任务 timer阶段   暂时命名任务3
setTimeout(()=>{
	console.log(3);
},0);
//宏任务 timer阶段   暂时命名任务4
setTimeout(()=>{
	console.log(4);
},100);

//微任务              暂时命名任务5
process.nextTick(()=>{     
	console.log(5);
})
//同步任务                 暂时命名任务6
console.log(6);
console.log(7);
//执行结果为  6 7 5 2 3 1 22 4

我们看以上代码

步骤1 首先根据js执行顺序，从上到下依次执行，发现宏任务将任务放入下一个事件循环中，发现微任务，将其置入微任务队列中。将同步任务置入执行栈中。
步骤2 开始运行执行栈，其中有两行同步语句，输出 6 7，此时执行栈中运行完毕，主线程空闲；

步骤3 开始检查微任务队列，微任务队列中包含 process.nextTick，则输出5，微任务队列执行全部执行完毕，队列中再无其他微任务，则检查宏任务队列开始进行事件循环。

步骤4 事件循环进入第一阶段（timer阶段），检查是否有定时器超时的回调，此时发现队列中有两个回调（任务2和任务3回调）。
先执行任务2回调，输出 2。发现宏任务22，则将该任务放入下一次事件循环中（同步骤1。也同时符合执行一个宏任务则继续运行执行栈和微任务的解释）。
步骤5 任务2回调执行完毕，继续执行任务3回调。 （注意所有异步操作是后台操作完成可以触发回调函数时，才将回调函数放入对应阶段的队列中。所以此时timer队列中并无任务4回调） 。

步骤6 timer队列清空，事件循环进入下一阶段，依次到check阶段之前均为空队列，进入check阶段，执行任务1回调，输出1。继续进入close callback阶段。结束本次事件循环。
步骤7 进入下一个事件循环，timer阶段，队列中任务22回调，输出22。继续进入下面阶段，直到循环结束。
继续进入下一循环。。直到任务4超时回调触发 输出 4。

人生第一篇原创技术博文！

参考地址:
https://nodejs.org/zh-cn/docs/guides/event-loop-timers-and-nexttick/
https://www.cnblogs.com/linzhanfly/p/9082895.html

事件循环原理流程图

• timers：本阶段执行setTimeout()和setInterval()调度的回调函数
• pending callbacks：本阶段执行某些系统操作的回调函数，例如文件操作回调
• idle、prepare：本阶段仅系统内部使用，我们并不关心
• poll：检索新的I/O事件，执行与I/O相关的回调，以及其他几乎所有的回调
• check: 本阶段执行setImmediate()调度的回调函数
• close callbacks: 本阶段执行一些与关闭相关的回调函数，如 socket.on('close', ...)

特殊之处

• setTimeout 如果不设置时间，或者设置为0，则会默认为1ms
• 主流程执行完成后，超过1ms时，会将setTimeout回调函数插入到poll队列中

事件循环过程

宏任务

• setImmediate
• setTimeout
• setInterval
• 文件I/O

微任务(优先级高于宏任务)

• process.nextTick （优先级高于promise）
• promise

特殊之处

• 在浏览器的事件循环中，每次循环是清空微任务队列，再取一个宏任务执行
• 在NodeJS的事件循环中，每次循环是清空微任务队列后，同样清空宏任务队列

代码

const fs = require('fs')

setTimeout(()=>{
	console.log('1')
}, 0)

setImmediate(()=>{
	console.log('setImmediate1')
})

fs.readFile('./test.conf', {encoding: 'utf-8'}, (err, data)=>{
	if (err) throw err
	console.log('read file success')
})

Promise.resolve().then(()=>{
	console.log('poll callback')
})

console.log('2')
/*
1. 首先执行同步代码，输出 2
2. 再执行微任务队列，输出 poll callback
3. 再执行宏任务队列，按就绪顺序依次输出 1, setImmediate1
4. 文件读取成功后，将回调推入宏任务队列，再执行输出 read file success
*/

const fs = require('fs')

console.log('start')

fs.readFile('./test.conf', {encoding: 'utf-8'}, (err, data)=>{
	if (err) throw err
	console.log('read file success')
})

setTimeout(()=>{
	console.log('setTimeout')
}, 0)

Promise.resolve().then(()=>{
	console.log('Promise callback')
})

process.nextTick(()=>{
	console.log('nextTick callback')
})

console.log('end')

/*
1. 首先执行同步代码，依次输出 start、end
2. 再执行微任务队列，按优先级依次输出 nextTick callback、Promise callback
3. 再执行宏任务队列，按就绪顺序依次输出 setTimeout、read file success
同样由于文件I/0比较慢，因此输出结果在最后
*/

const fs = require('fs')

setTimeout(()=>{
	console.log('1')
	fs.readFile('./config/test.conf', {encoding: 'utf-8'}, (err, data)=>{
		if (err) throw err
		console.log('read file success in setTimeout')
	})
}, 0)

fs.readFile('./config/test.conf', {encoding: 'utf-8'}, (err, data)=>{
	if (err) throw err
	console.log('read file success')
})

Promise.resolve().then(()=>{
	console.log('poll callback')
})

console.log('2')
/*
1. 首先执行同步代码，输出 2
2. 再执行微任务队列，输出 poll callback
3. 再执行宏任务队列，输出 1，接着又进行了读文件，现在还剩下两个I/0的回调
4. 按合理的情况来说，两个读文件都是读的相同的文件，因此谁先开始读谁的回调就先执行，
按照回调就绪的顺序进行打印，read file success 、read file success in setTimeout
*/

Node.js 采用事件驱动和异步 I/O 的方式，实现了一个单线程、高并发的 JavaScript 运行时环境，而单线程就意味着同一时间只能做一件事，那么 Node.js 如何通过单线程来实现高并发和异步 I/O？本文将围绕这个问题来探讨 Node.js 的单线程模型 。

高并发策略

一般来说，高并发的解决方案就是提供多线程模型，服务器为每个客户端请求分配一个线程，使用同步 I/O，系统通过线程切换来弥补同步 I/O 调用的时间开销。比如 Apache 就是这种策略，由于 I/O 一般都是耗时操作，因此这种策略很难实现高性能，但非常简单，可以实现复杂的交互逻辑。

而事实上，大多数网站的服务器端都不会做太多的计算，它们接收到请求以后，把请求交给其它服务来处理（比如读取数据库），然后等着结果返回，最后再把结果发给客户端。因此，Node.js 针对这一事实采用了单线程模型来处理，它不会为每个接入请求分配一个线程，而是用一个主线程处理所有的请求，然后对 I/O 操作进行异步处理，避开了创建、销毁线程以及在线程间切换所需的开销和复杂性。

事件循环

Node.js 在主线程里维护了一个事件队列，当接到请求后，就将该请求作为一个事件放入这个队列中，然后继续接收其他请求。当主线程空闲时(没有请求接入时)，就开始循环事件队列，检查队列中是否有要处理的事件，这时要分两种情况：如果是非 I/O 任务，就亲自处理，并通过回调函数返回到上层调用；如果是 I/O 任务，就从 线程池 中拿出一个线程来处理这个事件，并指定回调函数，然后继续循环队列中的其他事件。

当线程中的 I/O 任务完成以后，就执行指定的回调函数，并把这个完成的事件放到事件队列的尾部，等待事件循环，当主线程再次循环到该事件时，就直接处理并返回给上层调用。 这个过程就叫 事件循环 (Event Loop)，其运行原理如下图所示：

这个图是整个 Node.js 的运行原理，从左到右，从上到下，Node.js 被分为了四层，分别是 应用层、V8引擎层、Node API层 和 LIBUV层。

应用层：   即 JavaScript 交互层，常见的就是 Node.js 的模块，比如 http，fs

V8引擎层：  即利用 V8 引擎来解析JavaScript 语法，进而和下层 API 交互

NodeAPI层：  为上层模块提供系统调用，一般是由 C 语言来实现，和操作系统进行交互 。

LIBUV层： 是跨平台的底层封装，实现了 事件循环、文件操作等，是 Node.js 实现异步的核心 。

无论是 Linux 平台还是 Windows 平台，Node.js 内部都是通过 线程池 来完成异步 I/O 操作的，而 LIBUV 针对不同平台的差异性实现了统一调用。因此，Node.js 的单线程仅仅是指 JavaScript 运行在单线程中，而并非 Node.js 是单线程。

工作原理

Node.js 实现异步的核心是事件，也就是说，它把每一个任务都当成 事件 来处理，然后通过 Event Loop 模拟了异步的效果，为了更具体、更清晰的理解和接受这个事实，下面我们用伪代码来描述一下其工作原理 。

【1】定义事件队列

既然是队列，那就是一个先进先出 (FIFO) 的数据结构，我们用JS数组来描述，如下：

/**
 * 定义事件队列
 * 入队：push()
 * 出队：shift()
 * 空队列：length == 0
 */
globalEventQueue: []

我们利用数组来模拟队列结构：数组的第一个元素是队列的头部，数组的最后一个元素是队列的尾部，push() 就是在队列尾部插入一个元素，shift() 就是从队列头部弹出一个元素。这样就实现了一个简单的事件队列。

【2】定义接收请求入口

每一个请求都会被拦截并进入处理函数，如下所示： 

/**
 * 接收用户请求
 * 每一个请求都会进入到该函数
 * 传递参数request和response
 */
processHttpRequest:function(request,response){
    
    // 定义一个事件对象
    var event = createEvent({
        params:request.params, // 传递请求参数
        result:null, // 存放请求结果
        callback:function(){} // 指定回调函数
    });

    // 在队列的尾部添加该事件   
    globalEventQueue.push(event);
}

这个函数很简单，就是把用户的请求包装成事件，放到队列里，然后继续接收其他请求。

【3】定义 Event Loop

当主线程处于空闲时就开始循环事件队列，所以我们还要定义一个函数来循环事件队列： 

/**
 * 事件循环主体，主线程择机执行
 * 循环遍历事件队列
 * 处理非IO任务
 * 处理IO任务
 * 执行回调，返回给上层
 */
eventLoop:function(){
    // 如果队列不为空，就继续循环
    while(this.globalEventQueue.length > 0){
        
        // 从队列的头部拿出一个事件
        var event = this.globalEventQueue.shift();
        
        // 如果是耗时任务
        if(isIOTask(event)){
            // 从线程池里拿出一个线程
            var thread = getThreadFromThreadPool();
            // 交给线程处理
            thread.handleIOTask(event)
        }else {
            // 非耗时任务处理后，直接返回结果
            var result = handleEvent(event);
            // 最终通过回调函数返回给V8，再由V8返回给应用程序
            event.callback.call(null,result);
        }
    }
}

主线程不停的检测事件队列，对于 I/O 任务，就交给线程池来处理，非 I/O 任务就自己处理并返回。

【4】处理 I/O 任务

线程池接到任务以后，直接处理IO操作，比如读取数据库：

/**
 * 处理IO任务
 * 完成后将事件添加到队列尾部
 * 释放线程
 */
handleIOTask:function(event){
    //当前线程
    var curThread = this; 

    // 操作数据库
    var optDatabase = function(params,callback){
        var result = readDataFromDb(params);
        callback.call(null,result)
    };
    
    // 执行IO任务
    optDatabase(event.params,function(result){
        // 返回结果存入事件对象中
        event.result = result; 

        // IO完成后，将不再是耗时任务
        event.isIOTask = false; 
        
        // 将该事件重新添加到队列的尾部
        this.globalEventQueue.push(event);
        
        // 释放当前线程
        releaseThread(curThread)
    })
}

当 I/O 任务完成以后就执行回调，把请求结果存入事件中，并将该事件重新放入队列中，等待循环，最后释放当前线程，当主线程再次循环到该事件时，就直接处理了。

总结以上过程我们发现，Node.js 只用了一个主线程来接收请求，但它接收请求以后并没有直接做处理，而是放到了事件队列中，然后又去接收其他请求了，空闲的时候，再通过 Event Loop 来处理这些事件，从而实现了异步效果，当然对于IO类任务还需要依赖于系统层面的线程池来处理。

因此，我们可以简单的理解为：Node.js 本身是一个多线程平台，而它对 JavaScript 层面的任务处理是单线程的。

CPU密集型是短板

至此，对于 Node.js 的单线程模型，我们应该有了一个简单而又清晰的认识，它通过事件驱动模型实现了高并发和异步 I/O，然而也有 Node.js 不擅长做的事情：

上面提到，如果是 I/O 任务，Node.js 就把任务交给线程池来异步处理，高效简单，因此 Node.js 适合处理I/O密集型任务。但不是所有的任务都是 I/O 密集型任务，当碰到CPU密集型任务时，即只用CPU计算的操作，比如要对数据加解密(node.bcrypt.js)，数据压缩和解压(node-tar)，这时 Node.js 就会亲自处理，一个一个的计算，前面的任务没有执行完，后面的任务就只能干等着 。如下图所示：

在事件队列中，如果前面的 CPU 计算任务没有完成，后面的任务就会被阻塞，出现响应缓慢的情况，如果操作系统本身就是单核，那也就算了，但现在大部分服务器都是多 CPU 或多核的，而 Node.js 只有一个 EventLoop，也就是只占用一个 CPU 内核，当 Node.js 被CPU 密集型任务占用，导致其他任务被阻塞时，却还有 CPU 内核处于闲置状态，造成资源浪费。

因此，Node.js 并不适合 CPU 密集型任务。

适用场景

RESTful API - 请求和响应只需少量文本，并且不需要大量逻辑处理， 因此可以并发处理数万条连接。

聊天服务 - 轻量级、高流量，没有复杂的计算逻辑。

原创发布  @一像素  2017.07　　

参考文献：

[1] Node.js软肋之CPU密集型任务

[2] nodejs笔记之：事件驱动，线程池，非阻塞，异常处理等

[3] Node.js机制及原理理解初步

Copyright © 2022 一像素
Powered by .NET 6 on Kubernetes