Node事件循环和浏览器事件循环的区别
首先我们要搞懂什么是进程?什么是线程?
JavaScript 是一门单线程语言,指的是一个进程里只有一个主线程。
进程是 CPU 资源分配的最小单位,而线程是 CPU 调度的最小单位。
那线程和进程之间的关系是怎样的呢?
一个进程由一个或多个线程组成,线程是一个进程中代码的不同执行路线。
一个进程的内存空间是共享的,每个线程都可用这些共享内存。
接着来看多线程和多进程的概念:
多进程:
在同一个时间里,同一个计算机系统中如果允许两个或两个以上的进程处于运行状态。多进程带来的好处是明显的,比如你可以在听歌的同时,打开编辑器敲代码,编辑器和听歌软件的进程之间丝毫不会相互干扰。而在浏览器中,当你打开一个 Tab 页时,其实就是创建了一个进程。
多线程:
程序中包含多个执行流,即在一个程序中可以同时运行多个不同的线程来执行不同的任务,也就是说允许单个程序创建多个并行执行的线程来完成各自的任务。一个进程中可以有多个线程,比如渲染线程、JS 引擎线程、HTTP 请求线程等等。
搞懂了进程和线程,我们来看看浏览器内核
简单来说浏览器内核是通过取得页面内容、整理信息(应用 CSS )、计算和组合最终输出可视化的图像结果,通常也被称为渲染引擎。
浏览器内核是多线程,在内核控制下各线程相互配合以保持同步,一个浏览器通常由以下常驻线程组成:
GUI渲染线程
● 主要负责页面的渲染,解析 HTML、CSS,构建 DOM 树,布局和绘制等。
● 当界面需要重绘或者由于某种操作引发回流时,将执行该线程。
● 该线程与 JS 引擎线程互斥,当执行 JS 引擎线程时,GUI 渲染会被挂起,当任务队列空闲时,主线程才会去执行 GUI 渲染。
JavaScript引擎线程
● 该线程当然是主要负责处理 JavaScript 脚本,执行代码。
● 也是主要负责执行准备好待执行的事件,即定时器计数结束,或者异步请求成功并正确返回时,将依次进入任务队列,等待 JS 引擎线程的执行。
● 当然,该线程与 GUI 渲染线程互斥,当 JS 引擎线程执行 JavaScript 脚本时间过长,将导致页面渲染的阻塞。
定时器触发线程
● 负责执行异步定时器一类的函数的线程,如:setTimeout、setInterval。
● 主线程依次执行代码时,遇到定时器,会将定时器交给该线程处理,当计数完毕后,事件触发线程会将计数完毕后的事件加入到任务队列的尾部,等待 JS 引擎线程执行。
事件触发线程
● 主要负责将准备好的事件交给 JS 引擎线程执行。比如 setTimeout 定时器计数结束, ajax 等异步请求成功并触发回调函数,或者用户触发点击事件时,该线程会将整装待发的事件依次加入到任务队列的队尾,等待 JS 引擎线程的执行。
异步http请求线程
● 负责执行异步请求一类的函数的线程,如:Promise、fetch、ajax 等。
● 主线程依次执行代码时,遇到异步请求,会将函数交给该线程处理,当监听到状态码变更,如果有回调函数,事件触发线程会将回调函数加入到任务队列的尾部,等待 JS 引擎线程执行。
浏览器中的事件循环
事件循环中的队列有两种:
宏任务(macrotask):dom事件回调、ajax回调、定时器回调
script(整体代码)、setTimeout、setInterval、(setImmediate,I/O、UI交互事件)Node)
微任务(microtask):promise.then、process.nextTick(Node)、Object.observe、MutationObserver
宏任务和微任务的执行流程:
Node.js中的事件循环
Node.js 中的事件循环和浏览器中的是完全不相同的东西。
Node.js 采用 V8 作为 JS 的解析引擎,而 I/O 处理方面使用了自己设计的 libuv,libuv 是一个基于事件驱动的跨平台抽象层,封装了不同操作系统一些底层特性,对外提供统一的 API,事件循环机制也是它里面的实现。
可以看出 Node.JS 的事件循环比浏览器端复杂很多。Node.js 的运行机制如下:
- V8 引擎解析 JavaScript 脚本。
- 解析后的代码,调用 Node API。
- libuv 库负责 Node API 的执行。它将不同的任务分配给不同的线程,形成一个事件循环,以异步的方式将任务的执行结果返回给 V8 引擎。
- V8 引擎再将结果返回给用户。
事件循环的6个阶段:
timers 阶段:这个阶段执行 timer( setTimeout、setInterval )的回调
timers 阶段会执行 setTimeout 和 setInterval 回调,并且是由 poll 阶段控制的。同样,在 Node.js 中定时器指定的时间也不是准确时间,只能是尽快执行。
I/O callbacks 阶段:处理一些上一轮循环中的少数未执行的 I/O 回调
idle、prepare 阶段:仅 Node.js 内部使用
poll 阶段:获取新的 I/O 事件, 适当的条件下 Node.js 将阻塞在这里
poll 是一个至关重要的阶段,这一阶段中,系统会做两件事情:
● 回到 timers 阶段执行回调
● 执行 I/O 回调
并且在进入该阶段时如果没有设定了 timer 的话,会发生以下两件事情:
● 如果 poll 队列不为空,会遍历回调队列并同步执行,直到队列为空或者达到系统限制
● 如果 poll 队列为空时,会有两件事发生:
○ 如果有 setImmediate 回调需要执行,poll 阶段会停止并且进入到 check 阶段执行回调
○ 如果没有 setImmediate 回调需要执行,会等待回调被加入到队列中并立即执行回调,这里同样会有个超时时间设置防止一直等待下去
当然设定了 timer 的话且 poll 队列为空,则会判断是否有 timer 超时,如果有的话会回到 timer 阶段执行回调。
假设 poll 被堵塞,那么即使 timer 已经到时间了也只能等着,这也是为什么上面说定时器指定的时间并不是准确的时间。
check 阶段:执行 setImmediate( ) 的回调
setImmediate( ) 的回调会被加入 check 队列中,从事件循环的阶段图可以知道,check 阶段的执行顺序在 poll 阶段之后。
close callbacks 阶段:执行 socket 的 close 事件回调
从上图中,大致看出 Node.js 中的事件循环的顺序:
外部输入数据 –-> 轮询阶段( poll )-–> 检查阶段( check )-–> 关闭事件回调阶段( close callback )–-> 定时器检测阶段( timer )–-> I/O 事件回调阶段( I/O callbacks )-–>闲置阶段( idle、prepare )–->轮询阶段(按照该顺序反复运行)…
Node.js 与浏览器的事件队列的差异
浏览器环境下,就两个队列,一个宏任务队列,一个微任务队列。微任务的任务队列是每个宏任务执行完之后执行。
在 Node.js 中,每个任务队列的每个任务执行完毕之后,就会清空这个微任务队列。
补充
process.nextTick
这个函数其实是独立于事件循环之外的,它有一个自己的队列。当每个阶段完成后,如果存在 nextTick 队列,就会清空队列中的所有回调函数,并且优先于其他 microtask 执行。
Promise.then
Promise.then 也是独立于事件循环之外的,有一个自己的队列,但是优先级要比 process.nextTick 要低,所以当微任务中同时存在 process.nextTick 和 Promise.then 时,会优先执行前者。
附加内容
JS在node端和浏览器端的区别: