https://juejin.cn/post/6844903761949753352

浏览器的内核

1.GUI渲染线程

  • 主要负责页面的渲染，解析HTML、CSS，构建DOM树，布局和绘制等。
  • 当界面需要重绘或者由于某种操作引发回流时，将执行该线程。

  • 该线程与JS引擎线程互斥，当执行JS引擎线程时，GUI渲染会被挂起，当任务队列空闲时，主线程才会去执行GUI渲染。

    2.JS引擎线程

  • 该线程当然是主要负责处理 JavaScript脚本，执行代码。

  • 也是主要负责执行准备好待执行的事件，即定时器计数结束，或者异步请求成功并正确返回时，将依次进入任务队列，等待 JS引擎线程的执行。

  • 当然，该线程与 GUI渲染线程互斥，当 JS引擎线程执行 JavaScript脚本时间过长，将导致页面渲染的阻塞。

    3.定时器触发线程

  • 负责执行异步定时器一类的函数的线程，如： setTimeout，setInterval。

  • 主线程依次执行代码时，遇到定时器，会将定时器交给该线程处理，当计数完毕后，事件触发线程会将计数完毕后的事件加入到任务队列的尾部，等待JS引擎线程执行。

    4.事件触发线程

  • 主要负责将准备好的事件交给 JS引擎线程执行。

比如 setTimeout定时器计数结束， ajax等异步请求成功并触发回调函数，或者用户触发点击事件时，该线程会将整装待发的事件依次加入到任务队列的队尾，等待 JS引擎线程的执行。

5.异步http请求线程

  • 负责执行异步请求一类的函数的线程，如： Promise，axios，ajax等。
  • 主线程依次执行代码时，遇到异步请求，会将函数交给该线程处理，当监听到状态码变更，如果有回调函数，事件触发线程会将回调函数加入到任务队列的尾部，等待JS引擎线程执行。

浏览器中的eventloop

浏览器中完整loop 可以概括为以下阶段
image.png

  • 一开始执行栈空,我们可以把执行栈认为是一个存储函数调用的栈结构，遵循先进后出的原则。micro 队列空，macro 队列里有且只有一个 script 脚本（整体代码）。
  • 全局上下文（script 标签）被推入执行栈，同步代码执行。在执行的过程中，会判断是同步任务还是异步任务，通过对一些接口的调用，可以产生新的 macro-task 与 micro-task，它们会分别被推入各自的任务队列里。同步代码执行完了，script 脚本会被移出 macro 队列，这个过程本质上是队列的 macro-task 的执行和出队的过程。
  • 上一步我们出队的是一个 macro-task，这一步我们处理的是 micro-task。但需要注意的是：当 macro-task 出队时，任务是一个一个执行的；而 micro-task 出队时，任务是一队一队执行的。因此，我们处理 micro 队列这一步，会逐个执行队列中的任务并把它出队，直到队列被清空。
  • 执行渲染操作，更新界面
  • 检查是否存在 Web worker 任务，如果有，则对其进行处理
  • 上述过程循环往复，直到两个队列都清空

node中的event loop

Node 中的 Event Loop 和浏览器中的是完全不相同的东西。Node.js采用V8作为js的解析引擎，而I/O处理方面使用了自己设计的libuv，libuv是一个基于事件驱动的跨平台抽象层，封装了不同操作系统一些底层特性，对外提供统一的API，事件循环机制也是它里面的实现（下文会详细介绍）。

Node.js的运行机制如下:

  • V8引擎解析JavaScript脚本。
  • 解析后的代码，调用Node API。
  • libuv库负责Node API的执行。它将不同的任务分配给不同的线程，形成一个Event Loop（事件循环），以异步的方式将任务的执行结果返回给V8引擎。
  • V8引擎再将结果返回给用户。

六个阶段

其中libuv引擎中的事件循环分为 6 个阶段，它们会按照顺序反复运行。每当进入某一个阶段的时候，都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值，就会进入下一阶段。
image.png›
外部输入数据—>轮询阶段(poll)—>检查阶段(check)—>关闭事件回调阶段(close callback)—>定时器检测阶段(timer)—>I/O事件回调阶段(I/O callbacks)—>闲置阶段(idle, prepare)—>轮询阶段（按照该顺序反复运行）…

  • timers 阶段：这个阶段执行timer（setTimeout、setInterval）的回调
  • I/O callbacks 阶段：处理一些上一轮循环中的少数未执行的 I/O 回调
  • idle, prepare 阶段：仅node内部使用
  • poll 阶段：获取新的I/O事件, 适当的条件下node将阻塞在这里
  • check 阶段：执行 setImmediate() 的回调
  • close callbacks 阶段：执行 socket 的 close 事件回调

注意：上面六个阶段都不包括 process.nextTick()(下文会介绍)
接下去我们详细介绍timers、poll、check这3个阶段，因为日常开发中的绝大部分异步任务都是在这3个阶段处理的。

(1) timer

timers 阶段会执行 setTimeout 和 setInterval 回调，并且是由 poll 阶段控制的。 同样，在 Node 中定时器指定的时间也不是准确时间，只能是尽快执行。

(2) poll

poll 是一个至关重要的阶段，这一阶段中，系统会做两件事情
1.回到 timer 阶段执行回调
2.执行 I/O 回调
并且在进入该阶段时如果没有设定了 timer 的话，会发生以下两件事情

  • 如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者达到系统限制
  • 如果 poll 队列为空时，会有两件事发生
    • 如果有 setImmediate 回调需要执行，poll 阶段会停止并且进入到 check 阶段执行回调
    • 如果没有 setImmediate 回调需要执行，会等待回调被加入到队列中并立即执行回调，这里同样会有个超时时间设置防止一直等待下去

当然设定了 timer 的话且 poll 队列为空，则会判断是否有 timer 超时，如果有的话会回到 timer 阶段执行回调。

(3) check阶段

setImmediate()的回调会被加入check队列中，从event loop的阶段图可以知道，check阶段的执行顺序在poll阶段之后。 我们先来看个例子:

  1. console.log('start')
  2. setTimeout(() => {
  3.   console.log('timer1')
  4.   Promise.resolve().then(function() {
  5.     console.log('promise1')
  6.   })
  7. }, 0)
  8. setTimeout(() => {
  9.   console.log('timer2')
  10.   Promise.resolve().then(function() {
  11.     console.log('promise2')
  12.   })
  13. }, 0)
  14. Promise.resolve().then(function() {
  15.   console.log('promise3')
  16. })
  17. console.log('end')
  18. // node10和以前版本中的顺序
  19. //start=>end=>promise3=>timer1=>timer2=>promise1=>promise2
  20. // node11及以上版本 和 浏览器中的顺序
  21. start => end => promise3 => timer1 => promise1 => timer2 => promise2
  22. 复制代码
  • 一开始执行栈的同步任务（这属于宏任务）执行完毕后（依次打印出start end，并将2个timer依次放入timer队列）,会先去执行微任务（这点跟浏览器端的一样），所以打印出promise3
  • 然后进入timers阶段，执行timer1的回调函数，打印timer1，并将promise.then回调放入microtask队列，同样的步骤执行timer2，打印timer2；这点跟浏览器端相差比较大，timers阶段有几个setTimeout/setInterval都会依次执行，并不像浏览器端，每执行一个宏任务后就去执行一个微任务（关于Node与浏览器的 Event Loop 差异，下文还会详细介绍）。

process.nextTick

这个函数其实是独立于 Event Loop 之外的，它有一个自己的队列，当每个阶段完成后，如果存在 nextTick 队列，就会清空队列中的所有回调函数，并且优先于其他 microtask 执行。

  1. Promise.resolve().then(function () {
  2.     console.log('promise1')
  3. })
  5. process.nextTick(() => {
  6.     console.log('nextTick')
  7.     process.nextTick(() => {
  8.         console.log('nextTick')
  9.         process.nextTick(() => {
  10.             console.log('nextTick')
  11.             process.nextTick(() => {
  12.                 console.log('nextTick')
  13.             })
  14.         })
  15.     })
  16. })
  17. // nextTick=>nextTick=>nextTick=>nextTick=>promise1

Node与浏览器的 Event Loop 差异

浏览器环境下，microtask的任务队列是每个macrotask执行完之后执行。而在Node.js中，microtask会在事件循环的各个阶段之间执行，也就是一个阶段执行完毕，就会去执行microtask队列的任务。

image.png

由于node版本更新到11，Event Loop运行原理发生了变化，一旦执行一个阶段里的一个宏任务(setTimeout,setInterval和setImmediate)就立刻执行微任务队列，这点就跟浏览器端一致。

代码输出顺序 node执行以下代码

  1. setTimeout(()=>{
  2.     console.log('timeout')
  3. },0)
  5. setImmediate(()=>{
  6.     console.log('immdediate')
  7. })
  10. // 输出顺序不固定
  12. // immdediate
  13. // timeout
  15. // timeout
  16. // immdediate

默认情况下 settimeout 0 和 setImmediate是不分先后的 

  1. const fs = require('fs')
  3. fs.readFile('./m.js',()=>{
  4.     setTimeout(()=>{
  5.         console.log('timeout')
  6.     },0)
  8.     setImmediate(()=>{
  9.         console.log('immdediate')
  10.     })
  11. })
  14. // immdediate
  15. // timeout

但是把他们放进io 的callback就不一样了
按照nodejs宏任务队列的顺序， io callback是在poll队列中的， 执行完poll队列就会到了check阶段 因此setImmediate先执行

截屏2021-07-22 下午9.09.49.png