Event Loop 异步编程模型 (By Node.js)

Node.js — Asynchronous flow control

Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.

https://nodejs.org/en/learn/asynchronous-work/asynchronous-flow-control

处理异步编程的模型 : 对比 Golang Goroutine

go handleConn(conn) { ... }
// 哪怕 handleConn 很重，它阻塞的是当前 Goroutine，不会影响其他 Goroutine 的调度运行。

• 异步执行的代码都使用 calback 打包，注册到队列中，等待稍后的 Event loop 处理执行。

• Event loop 将对应的异步分发给不同的底层模块：例如网络 / File 读取 (统称 IO)

• callback 则在队列中排队 (FIFO)

• 当底层 IO 处理完毕，通知到 Event loop 的 poll 阶段 (被 libuv 管理实现)，然后在排队执行队列中的各个 callback

• 注意 callback 都是在主线程上执行的 (Event loop 中的各种类型的 callback 都在主线程执行)，所以如果有 1000 个并发请求，那么当响应回来后，理论上就会有 1000个 callback 需要排队处理，这个处理过程是单线程的，吞吐效率自然低。所以能体会到为什么说 Go 对与处理并发编程有天然优势了吧，也许 Go 发明的初衷就是解决基于事件驱动模型并发吞吐低的问题 (猜测)。

注意：不是说 Event loop 要同步处理 1000 个网络请求，而是网络请求的 callback 回调。真正的网络请求会由 Network Service 模块处理(内部维护着线程池)，由 Event loop 来负责调度。

• Node.js 有 process.nextTick，这个比 microTask 微任务执行还要早的队列，在 Web 浏览器中没有这个 Tick，但是有 queueMicroTask。

• Promise 微任务对两者都是一样的，因为 Promise 被 V8 引擎维护和实现，是语言层面的。

• setImmediate 也是 Node.js 专有的。

• 另外 Node.js 更侧重 IO (网络请求和File读取)，所以它更看重优先处理 IO，这个在 poll 阶段处理，甚至 Timer (setTimeout/setInterval) 的执行也由 poll 阶段的处理结果来决策。

阻塞式和非阻塞式 (blocking & non-blocking)

• 在 Node.js 中，一般认为 CPU 密集型的为非阻塞式操作，可以立即被 CPU 执行。non-blocking

• I/O (网络+File访问)为阻塞式 blocking operation
• 遇到 I/O，事件循环需要暂停 (阻塞等待机制)

• 阻塞式 IO，一般使用 async 调用处理

Event Loop 一次执行总览：

console.log('script start');      // 进调用栈

setTimeout(() => {                // 异步：进 Timer 队列
  console.log('setTimeout');
}, 0);

Promise.resolve().then(() => {    // 异步: 进入 promise 微任务队列
  console.log('promise1');
}).then(() => {
  console.log('promise2');
});

process.nextTick(() => {          // 异步: 进入 tick 微任务队列
    console.log('nextTick');
});

console.log('script end');        // 进主调用栈

// IMPORTANT: 我们依次分析上边的代码：

/*** 第一阶段：调用栈阶段 (同步) ***/

// 1: console.log('script start'); 压栈 -> 执行 -> pop 出栈
// 2: 中间的异步执行都进入各自的队列 ...
// 3: console.log('script end'); 压栈 -> 执行 -> pop 出栈
// 到这里 ('script end' 输出后), 主调用栈为空，开始依次检查：

/*** 第二阶段：微任务队列 ***/

// 1: Tick 微任务队列
// 2: promise 微任务duilie 

/*** 第三阶段: 执行 Event loop 下一个阶段 ***/

// 1: 执行 Event loop 下一阶段
// 2: Event loop 某个宏任务阶段开始执行
// 每个阶段的执行，使用和第一、第二阶段相同的步骤：
// 主栈执行 --> 主栈清空，开始检查微任务队列执行 -->  Event loop 下一阶段

// 输出:
script start
script end
nextTick
promise1
promise2
setTimeout

Event loop 是什么

Event loop 的工作时机 — 栈空,微任务执行情况后

1. 当当前的调用栈清空(同步代码执行完毕)，

2. 开始执行微任务队列

3. 然后 Eventloop 工作，Event loop 进入下一个工作阶段

4. 回到 1 继续循环，没有事件则休眠…

Timers 阶段

为了整体清晰一些，每个阶段末尾的微任务队列执行忽略，不在这里赘述了，前文已经解释

• setTimeout

• setInterval

Pending 阶段

• 处理各种异常，错误回调

• 处理上一次 Event loop poll 阶段来不及执行的 callback

idle prepare

• libuv 内部维护和私有调用

• 空闲和准备阶段，开发一般无法调用到

Poll 阶段

• Network 请求

• File 读取

这里可以类比，操作系统， 过渡等待 IO 密集型任务，会让 CPU 密集型的任务得不到执行，CPU 长时间空闲，产生 CPU 饥饿。

• 如果 poll 阶段，需要执行的队列为空，则立即回头检查 Timer 阶段的callback，处理时间到达的 callback。
• 如果此时没有后续阶段的 callback (check阶段)，Event loop 就此进入休眠，阻塞等待下次 IO 的到来，被唤醒。

• 如果 poll 阶段，需要执行的队列不为空，则执行最大长度的队列任务后：
• 把剩余的callback加入到之前的 Pending 阶段，下次 Event loop 再执行
• 立即调用 check 阶段 (主要为了执行 setImmediate)
• 检查 Timers 时间到了的 callback，执行 Timers

const fs = require('fs');

fs.readFile(__filename, () => {
  // IO
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
});

// 总是输出：
immediate
timeout

console.log('start')
setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));
console.log('end')

// 输出:
start
end
timeout / immediate (先后不确定，要看 CPU 调度)

Check 阶段 (Poll 想进入阻塞前的一个检查)

• Poll 阶段结束，检查 check 阶段来收取，是否有额外的 setImmediate 要执行

• 如果没有，Poll 则可以进入阻塞休眠，继续在 Poll 阶段等待 (例如等待网络请求回来后，再醒来)

• 如果开发者注册了执行，那么 Poll 阶段不会进入阻塞等待，而是继续循环执行后续阶段 (check —> close → Timers → …Poll → … )

• 这一定程度会节省性能，避免 Event loop 永远无效的循环等待下去。

Close 阶段

理解 Process.nextTick()

const EventEmitter = require('node:events');
class MyEmitter extends EventEmitter {
  constructor() {
    super();
    this.emit('event');
  }
}
const myEmitter = new MyEmitter();
// on 的时候， this.emit('event') 执行完成，所以无法监听到第一次的 emit
myEmitter.on('event', () => {
  console.log('an event occurred!');
});

constructor() {
    super();
    // 这是同步执行，先于 on 监听
    this.emit('event');
  }

const EventEmitter = require('node:events');
class MyEmitter extends EventEmitter {
  constructor() {
    super();
    // 在整个函数调用栈执行完，情况后，在emit，执行一定晚于任何地方的 on 的注册；
    process.nextTick(() => {
      this.emit('event');
    });
  }
}
const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
  console.log('an event occurred!');
});

Node.js 和 浏览器不同的架构模型对 Event loop 的区别实现

• 用户事件：点击 滑动 鼠标等…

• Dom 事件等

• Node.js 单进程，内部维护多线程
• Event loop 处理 IO 的时候，直接交够 IO 线程池

• 浏览器是多进程架构
• Network Service 服务被浏览器进程单独管理
• File manager 也是一个单独进程
• Event loop 被每个 tab 的渲染进程的主线程管理
• 所以 Event loop 进行 IO 的时候，会和 Network Service 发生 IPC (进程间通信)，这一点有别于 Node.js