成为自信的node.js 开发者（二）

时间 2019-11-17

标签成为自信 node.js node 开发者栏目 Node.js 繁體版

原文原文链接

这一章，咱们来学习一下event_loop, 本文内容旨在厘清浏览器（browsing context）和Node环境中不一样的 Event Loop。javascript

首先清楚一点：浏览器环境和 node环境的event-loop 彻底不同。java

浏览器环境

为了协调事件、用户交互、脚本、UI渲染、网络请求等行为，用户引擎必须使用Event Loop。event loop包含两类：基于browsing contexts，基于worker。node

本文讨论的浏览器中的EL基于browsing contextspromise

上面图中，关键性的两点：浏览器

同步任务直接进入主执行栈（call stack）中执行bash

等待主执行栈中任务执行完毕，由EL将异步任务推入主执行栈中执行网络

task——宏任务

task在网上也被成为macrotask （宏任务）dom

宏任务分类：

script代码异步

setTimeout/setIntervalsocket

setImmediate （未实现）

I/O

UI交互

宏任务特征

一个event loop 中，有一个或多个 task队列。

不一样的task会放入不一样的task队列中：好比，浏览器会为鼠标键盘事件分配一个task队列，为其余的事件分配另外的队列。

先进队列的先被执行

microtask——微任务

微任务

微任务的分类

一般下面几种任务被认为是microtask

promise（promise的then和catch才是microtask，自己其内部的代码并非）

MutationObserver

process.nextTick(nodejs环境中)

微任务特性

一个EL中只有一个microtask队列。

event-loop的循环过程

一个EL只要存在，就会不断执行下边的步骤：

先执行同步代码，全部微任务，一个宏任务，全部微任务（，更新渲染），一个宏任务，全部微任务（，更新渲染）...... 执行完microtask队列里的任务，有可能会渲染更新。在一帧之内的屡次dom变更浏览器不会当即响应，而是会积攒变更以最高60HZ的频率更新视图

例子

setTimeout(() => console.log('setTimeout1'), 0);
setTimeout(() => {
    console.log('setTimeout2');
    Promise.resolve().then(() => {
        console.log('promise3');
        Promise.resolve().then(() => {
            console.log('promise4');
        })
        console.log(5)
    })
    setTimeout(() => console.log('setTimeout4'), 0);
}, 0);
setTimeout(() => console.log('setTimeout3'), 0);
Promise.resolve().then(() => {
    console.log('promise1');
})
复制代码

打印出来的结果是：

promise1
setTimeout1
setTimeout2
'promise3'
5
promise4
setTimeout3
setTimeout4
复制代码

另一个例子：

console.log('script start')

async function async1() {
    await async2()
    console.log('async1 end')
}
async function async2() {
    console.log('async2 end')
}
async1()

setTimeout(function () {
    console.log('setTimeout')
}, 0)

new Promise(resolve => {
    console.log('Promise')
    resolve()
})
    .then(function () {
        console.log('promise1')
        setTimeout(() => {
            console.log('sssss')
        }, 0)
    })
    .then(function () {
        console.log('promise2')
    })

console.log('script end')
复制代码

在浏览器内输出结果以下, node内输出结果不一样

'script start'
'async2 end'
'Promise'
'script end'
'async1 end'
'promise1'
'promise2'
'setTimeout'
'sssss'
复制代码

await 只是 fn().then() 这些写法的语法糖，至关于 await 那一行代码下面的代码都被当成一个微任务，推入到了microtask queue 中
顺序：执行完同步任务，执行微任务队列中的所有的微任务，执行一个宏任务，执行所有的微任务

node 环境中

Node中的event-loop由 libuv库 实现，js是单线程的，会把回调和任务交给libuv

event loop 首先会在内部维持多个事件队列，好比时间队列、网络队列等等，而libuv会执行一个至关于 while true的无限循环，不断的检查各个事件队列上面是否有须要处理的pending状态事件，若是有则按顺序去触发队列里面保存的事件，同时因为libuv的事件循环每次只会执行一个回调，从而避免了竞争的发生

我的理解，它与浏览器中的轮询机制（一个task，全部microtasks；一个task，全部microtasks…）最大的不一样是，node轮询有phase（阶段）的概念，不一样的任务在不一样阶段执行，进入下一阶段以前执行全部的process.nextTick() 和全部的microtasks。

阶段

timers阶段

在这个阶段检查是否有超时的timer(setTimeout/setInterval)，有的话就执行他们的回调

但timer设定的阈值不是执行回调的确切时间（只是最短的间隔时间），node内核调度机制和其余的回调函数会推迟它的执行

由poll阶段来控制何时执行timers callbacks
复制代码

I/O callback 阶段

处理异步事件的回调，好比网络I/O，好比文件读取I/O，当这些事件报错的时候，会在 `I/O` callback阶段执行
复制代码

poll 阶段

这里是最重要的阶段，poll阶段主要的两个功能：

   处理poll queue的callbacks
    
   回到timers phase执行timers callbacks（当到达timers指定的时间时）
    

进入poll阶段，timer的设定有下面两种状况：

1.  event loop进入了poll阶段， **未设定timer**
    
       poll queue不为空：event loop将同步的执行queue里的callback，直到清空或执行的callback到达系统上限
        
       poll queue为空
        
           若是有设定` callback`, event loop将结束poll阶段进入check阶段，并执行check queue (check queue是 setImmediate设定的)
            
           若是代码没有设定setImmediate() callback，event loop将阻塞在该阶段等待callbacks加入poll queue
            
2.  event loop进入了 poll阶段， **设定了timer**
    
       若是poll进入空闲状态，event loop将检查timers，若是有1个或多个timers时间时间已经到达，event loop将回到 timers 阶段执行timers queue
        

这里的逻辑比较复杂，流程能够借助下面的图进行理解：

![](https://ws1.sinaimg.cn/large/006tKfTcgy1g0anodoa11j311i0h0t8w.jpg)
复制代码

check 阶段

一旦poll队列闲置下来或者是代码被`setImmediate`调度，EL会立刻进入check phase
复制代码

close callbacks

关闭I/O的动做，好比文件描述符的关闭，链接断开等

若是socket忽然中断，close事件会在这个阶段被触发
复制代码

同步的任务执行完，先执行彻底部的process.nextTick() 和所有的微任务队列，而后执行每个阶段，每一个阶段执行完毕后，

注意点

setTimeout 和 setImmediate

调用阶段不同
不一样的io中，执行顺序不保证

两者很是类似，区别主要在于调用时机不一样。

setImmediate 设计在poll阶段完成时执行，即check段；

setTimeout 设计在poll阶段为空闲时，且设定时间到达后执行，但它在timer阶段执行

setTimeout(function timeout () {
  console.log('timeout');
},0);
setImmediate(function immediate () {
  console.log('immediate');
});
复制代码

对于以上代码来讲，setTimeout 可能执行在前，也可能执行在后。首先 setTimeout(fn, 0) === setTimeout(fn, 1)，这是由源码决定的。

若是在准备时候花费了大于 1ms 的时间，那么在 timer 阶段就会直接执行 setTimeout 回调。若是准备时间花费小于 1ms，那么就是 setImmediate 回调先执行了。

也就是说，进入事件循环也是须要成本的。有可能进入event loop 时，setTimeout(fn, 1) 还在等待timer中，并无被推入到 time 事件队列，而setImmediate 方法已经被推入到了 check事件队列 中了。那么event_loop 按照time、i/o、poll、check、close 顺序执行，先执行immediate 任务。

也有可能，进入event loop 时，setTimeout(fn, 1) 已经结束了等待，被推到了time 阶段的队列中，以下图所示，则先执行了timeout 方法。

因此，setTimeout setImmediate 哪一个先执行，这主要取决于，进入event loop 花了多长时间。

但当两者在异步i/o callback内部调用时，老是先执行setImmediate，再执行setTimeout

const fs = require('fs')
fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log('timeout');
    }, 0)
    setImmediate(() => {
        console.log('immediate')
    })
})
复制代码

在上述代码中，setImmediate 永远先执行。由于两个代码写在 IO 回调中，IO 回调是在 poll 阶段执行，当回调执行完毕后队列为空，发现存在 setImmediate 回调，因此就直接跳转到 check 阶段去执行回调了。

process.nextTick() 和 setImmediate()

官方推荐使用 setImmediate()，由于更容易推理，也兼容更多的环境，例如浏览器环境

process.nextTick() 在当前循环阶段结束以前触发

setImmediate() 在下一个事件循环中的check阶段触发

经过process.nextTick()触发的回调也会在进入下一阶段前被执行结束，这会容许用户递归调用 process.nextTick() 形成I/O被榨干，使EL不能进入poll阶段

所以node做者推荐咱们尽可能使用setImmediate，由于它只在check阶段执行，不至于致使其余异步回调没法被执行到

例子

console.log('start')
setTimeout(() => {
  console.log('timer1')
  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)
setTimeout(() => {
  console.log('timer2')
  Promise.resolve().then(function() {
    console.log('promise2')
  })
}, 0)
Promise.resolve().then(function() {
  console.log('promise3')
})
console.log('end')
复制代码

注意：主栈执行完了以后，会先清空 process.nextick() 队列和microtask队列中的任务，而后按照每个阶段来执行先处理异步事件的回调，好比网络I/O，好比文件读取I/O。当这些I/O动做都结束的时候，在这个阶段会触发它们的

另一个例子

const {readFile} = require('fs')

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

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

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

readFile('./test.js', () => {
    console.log('4')
})

readFile(__filename, () => {
    console.log('5')
})

setImmediate(() => {
    console.log('当即回调')
})

process.nextTick(() => {
    console.log('process.nexttick的回调')
})

Promise.resolve().then(() => {

    process.nextTick(() => {
        console.log('nexttick 第二次回调')
    })
    console.log('6')
}).then(() => {
    console.log('7')
})
复制代码

上面代码的结果是：

process.nexttick的回调
6
7
nexttick 第二次回调
1
当即回调
4
5
2
3
复制代码

上面代码须要注意点:

下面两个回调任务，要等100ms 和 200ms 才能被推入到timers 阶段的任务队列
两个读取文件的回调，须要等待读取完成后，才能被推入到 poll 阶段的任务队列。（不是被推入到 io 阶段的任务队列，只有读取失败等异常的回调，才会被推入到 io 阶段的任务队列）
在微任务里面，新添加的process.nextTick() 也会在新阶段的开始以前被执行。简单理解为，在每个阶段的任务队列开始以前，都须要所有清空process.nextTick 和 microtask 任务队列

一个误区

本身在验证上面的想法的时候，实验过不少代码，从未失手过，可是当实验到下面的代码时：

Promise.resolve().then(() => {
    console.log(1)
    Promise.resolve().then(() => {
        console.log(2)
    })
}).then(() => {
    console.log(3)
})
复制代码

按照上面咱们讲的，这里应该是输出132, 可是反复验证，在 node 实际输出的是 123，连续好几天都不得其解，后来看到一个问答，才恍然大悟： stackoverflow.com/questions/3…

首先，上面的代码，在.then() 的回调函数中去执行promise.resolve(), 其实是，在目前的promise 链中新建了一个独立的 promise链 。你没有任何办法保证这两个哪一个先执行完，这其实是node引擎的一个bug，就像一口气发出两个请求，并不知道哪一个请求先返回。

每次咱们都能获得相同的结果是由于，咱们Promise.resolve()里面刚好没有异步的操做，这并非event-loop 专门设计成这样的。

因此，没必要花太多的时间，在上面的代码中，实际写代码中，也不会出现这种状况。

成为自信的node.js 开发者（二）