javascript中的事件循环机制

javaScript中的事件循环机制(Event Loop)

一、概念

​ JavaScript 有一个基于事件循环的并发模型，事件循环负责执行代码、收集和处理事件以及执行队列中的子任务。这个模型与其它语言中的模型截然不同，比如 C 和 Java。（摘自MDN）

​ 简单地说，对于 JS 运行中的任务，JS 有一套处理收集，排队，执行的特殊机制，我们把这套处理机制称为事件循环（Event Loop）。

单线程

​ JS 单线程指的是 javascript 引擎（如V8）在同一时刻只能处理一个任务。

​ 有人或许会问，异步任务 ajax 难道不是可以和 JS 代码同时执行么？

​ 答案是可以的，但是这和 JS 单线程并不冲突，前面说过 javascript 引擎（如V8）在同一时刻只能处理一个任务。但这并不是说浏览器在同一个时刻只能处理一件事情，实际上 ajax 等异步任务不是在 JS 引擎上运行的，ajax 在浏览器处理网络的模块中执行，此时不会影响到 JS 引擎的任务处理。

执行环境

​ 执行环境是 JS 代码语句执行的环境，包括全局执行环境和函数执行环境。

• 全局执行环境：全局环境是最外围的一个执行环境，根据ECMAScript实现所在的宿主环境不同，表示执行环境的对象也不一样，在web中，全局执行环境被认为是window对象。

• 函数执行环境：每个函数都有自己的执行环境。

  当一个任务执行时，相应的会对应一个动态变化的执行环境栈，这个执行环境栈包括了不同的执行环境，是一个后进先出的结构。

变量对象

​ 每个执行环境都有一个变量对象与之关联（一一对应），变量对象包含了执行环境中定义的所有变量及函数。（在此处可以思考下为什么我们提倡尽量少创建全局变量，答案就是因为全局环境对应的变量对象一直会存在内存中。）

二、浏览器内核中各个线程之间的关系

浏览器内核有多种线程在工作

• GUI 渲染线程:
  • 负责渲染页面，解析 HTML，CSS 构成 DOM 树等，当页面重绘或者由于某种操作引起回流都会调起该线程。
  • 和 JS 引擎线程是互斥的，当 JS 引擎线程在工作的时候，GUI 渲染线程会被挂起，GUI 更新被放入在 JS 任务队列中，等待 JS 引擎线程空闲的时候继续执行。
• JS 引擎线程:
  • 单线程工作，负责解析运行 JavaScript 脚本。
  • 和 GUI 渲染线程互斥，JS 运行耗时过长就会导致页面阻塞。
• 事件触发线程:
  • 当事件符合触发条件被触发时，该线程会把对应的事件回调函数添加到任务队列的队尾，等待 JS 引擎处理。
• 定时器触发线程:
  • 浏览器定时计数器并不是由 JS 引擎计数的，阻塞会导致计时不准确。
  • 开启定时器触发线程来计时并触发计时，计时完成后会被添加到任务队列中，等待 JS 引擎处理。
• http 请求线程:
  • http 请求的时候会开启一条请求线程。
  • 请求完成有结果了之后，将请求的回调函数添加到任务队列中，等待 JS 引擎处理。

GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。

因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起，
GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

JS阻塞页面加载

从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面。

譬如，假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存到队列中，等待JS引擎空闲后执行。
然后，由于巨量计算，所以JS引擎很可能很久很久后才能空闲，自然会感觉到巨卡无比。

所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。

WebWorker，JS的多线程？

前文中有提到JS引擎是单线程的，而且JS执行时间过长会阻塞页面，那么JS就真的对cpu密集型计算无能为力么？

所以，后来HTML5中支持了Web Worker。

MDN的官方解释是：

Web Worker为Web内容在后台线程中运行脚本提供了一种简单的方法。线程可以执行任务而不干扰用户界面 一个worker是使用一个构造函数创建的一个对象(e.g. Worker()) 运行一个命名的JavaScript文件 这个文件包含将在工作线程中运行的代码; workers 运行在另一个全局上下文中,不同于当前的window 因此，使用 window快捷方式获取当前全局的范围 (而不是self) 在一个 Worker 内将返回错误

这样理解下：

• 创建Worker时，JS引擎向浏览器申请开一个子线程（子线程是浏览器开的，完全受主线程控制，而且不能操作DOM）
• JS引擎线程与worker线程间通过特定的方式通信（postMessage API，需要通过序列化对象来与线程交互特定的数据）

所以，如果有非常耗时的工作，请单独开一个Worker线程，这样里面不管如何翻天覆地都不会影响JS引擎主线程，
只待计算出结果后，将结果通信给主线程即可，perfect!

而且注意下，JS引擎是单线程的，这一点的本质仍然未改变，Worker可以理解是浏览器给JS引擎开的外挂，专门用来解决那些大量计算问题。

三、javaScript事件循环机制

​ JavaScript 事件循环机制分为浏览器和 Node 事件循环机制，两者的实现技术不一样，浏览器 Event Loop 是 HTML 中定义的规范，Node Event Loop 是由 libuv 库实现。这里主要讲的是浏览器部分。

Javascript 有一个 main thread 主线程和 call-stack 调用栈(执行栈)，所有的任务都会被放到调用栈等待主线程执行。

• JS 调用栈

  JS 调用栈是一种后进先出的数据结构。当函数被调用时，会被添加到栈中的顶部，执行完成之后就从栈顶部移出该函数，直到栈内被清空。

• 同步任务、异步任务

  JavaScript 单线程中的任务分为同步任务和异步任务。同步任务会在调用栈中按照顺序排队等待主线程执行，异步任务则会在异步有了结果后将注册的回调函数添加到任务队列(消息队列)中等待主线程空闲的时候，也就是栈内被清空的时候，被读取到栈中等待主线程执行。任务队列是先进先出的数据结构。

• Event Loop

  调用栈中的同步任务都执行完毕，栈内被清空了，就代表主线程空闲了，这个时候就会去任务队列中按照顺序读取一个任务放入到栈中执行。每次栈内被清空，都会去读取任务队列有没有任务，有就读取执行，一直循环读取-执行的操作，就形成了事件循环。

• 定时器

  定时器会开启一条定时器触发线程来触发计时，定时器会在等待了指定的时间后将事件放入到任务队列中等待读取到主线程执行。

  定时器指定的延时毫秒数其实并不准确，因为定时器只是在到了指定的时间时将事件放入到任务队列中，必须要等到同步的任务和现有的任务队列中的事件全部执行完成之后，才会去读取定时器的事件到主线程执行，中间可能会存在耗时比较久的任务，那么就不可能保证在指定的时间执行。

• 宏任务(macro-task)、微任务(micro-task)

  除了广义的同步任务和异步任务，JavaScript 单线程中的任务可以细分为宏任务和微任务。

  • 宏任务（macro-task）：一般是 JS 引擎和宿主环境发生通信产生的回调任务，比如 setTimeout，setInterval 是浏览器进行计时的，其中回调函数的执行时间需要浏览器通知到 JS 引擎，网络模块, I/O处理的通信回调也是。包含有 setTimeout，setInterval，DOM事件回调，ajax请求结束后的回调，整体 script 代码，setImmediate（node.js主要是）。
  • 微任务（micro-task）：一般是宏任务在线程中执行时产生的回调，如 Promise，process.nextTick，Object.observe(已废弃)， MutationObserver（DOM监听），这些都是 JS 引擎自身可以监听到回调。

​ 上面我们了解了宏任务与微任务的分类，那么为什么我们要将其分为宏任务与微任务呢？主要是因为其添加到事件循环中的任务队列的机制不同。

​ 在事件循环中，任务一般都是由宏任务开始执行的（JS代码的加载执行），在宏任务的执行过程中，可能会产生新的宏任务和微任务，这时候宏任务（如ajax回调）会被添加到任务队列的末尾等待事件循环机制执行，而微任务则会被添加到当前任务队列的前端，也是等待事件循环机制的执行。

​ 其中相同类型的宏任务或微任务会按照回调的先后顺序进行排序，而不同任务类型的任务会有一定的优先级，按照不同类型任务区分

宏任务优先级，主代码块 > setImmediate > MessageChannel > setTimeout / setInterval

微任务优先级，process.nextTick > Promise > MutationObserver

照不同类型任务区分

宏任务优先级，主代码块 > setImmediate > MessageChannel > setTimeout / setInterval

微任务优先级，process.nextTick > Promise > MutationObserver