js事件循环机制（await-async-事件循环）

await和async

异步函数 async function

async关键字用于声明一个异步函数：
async是asynchronous单词的缩写，异步、非同步；
sync是synchronous单词的缩写，同步、同时；

async异步函数可以有很多中写法：

// await/async
async function foo1() {

}

const foo2 = async () => {

}

class Foo {
  async bar() {

  }
}

异步函数的执行流程

异步函数的内部代码执行过程和普通的函数是一致的，默认情况下也是会被同步执行。

异步函数有返回值时，和普通函数会有区别：

• 情况一：异步函数也可以有返回值，但是异步函数的返回值会被包裹到Promise.resolve中；
• 情况二：如果我们的异步函数的返回值是Promise，Promise.resolve的状态会由Promise决定；
• 情况三：如果我们的异步函数的返回值是一个对象并且实现了thenable，那么会由对象的then方法来决定；

如果我们在async中抛出了异常，那么程序它并不会像普通函数一样报错，而是会作为Promise的reject来传递；

await关键字

async函数另外一个特殊之处就是可以在它内部使用await关键字，而普通函数中是不可以的。

await关键字有什么特点呢？

• 通常使用await是后面会跟上一个表达式，这个表达式会返回一个Promise；
• 那么await会等到Promise的状态变成fulfilled状态，之后继续执行异步函数；

如果await后面是一个普通的值，那么会直接返回这个值；
如果await后面是一个thenable的对象，那么会根据对象的then方法调用来决定后续的值；
如果await后面的表达式，返回的Promise是reject的状态，那么会将这个reject结果直接作为函数的Promise的
reject值；

进程和线程

线程和进程是操作系统中的两个概念：

• 进程（process）：计算机已经运行的程序，是操作系统管理程序的一种方式；
• 线程（thread）：操作系统能够运行运算调度的最小单位，通常情况下它被包含在进程中；

听起来很抽象，这里还是给出我的解释：

• 进程：我们可以认为，启动一个应用程序，就会默认启动一个进程（也可能是多个进程）；
• 线程：每一个进程中，都会启动至少一个线程用来执行程序中的代码，这个线程被称之为主线程； p所以我们也可以说进程是线程的容器；

再用一个形象的例子解释：

• 操作系统类似于一个大工厂；
• 工厂中里有很多车间，这个车间就是进程；
• 每个车间可能有一个以上的工人在工厂，这个工人就是线程；

操作系统 – 进程 – 线程

操作系统的工作方式

操作系统是如何做到同时让多个进程（边听歌、边写代码、边查阅资料）同时工作呢？

• 这是因为CPU的运算速度非常快，它可以快速的在多个进程之间迅速的切换；
• 当我们进程中的线程获取到时间片时，就可以快速执行我们编写的代码；
• 对于用户来说是感受不到这种快速的切换的；

浏览器中的JavaScript线程

我们经常会说JavaScript是单线程的，但是JavaScript的线程应该有自己的容器进程：浏览器或者Node。

浏览器是一个进程吗，它里面只有一个线程吗？

• 目前多数的浏览器其实都是多进程的，当我们打开一个tab页面时就会开启一个新的进程，这是为了防止一个页 面卡死而造成所有页面无法响应，整个浏览器需要强制退出；
• 每个进程中又有很多的线程，其中包括执行JavaScript代码的线程；

JavaScript的代码执行是在一个单独的线程中执行的：

• 这就意味着JavaScript的代码，在同一个时刻只能做一件事；
• 如果这件事是非常耗时的，就意味着当前的线程就会被阻塞；

所以真正耗时的操作，实际上并不是由JavaScript线程在执行的：

• 浏览器的每个进程是多线程的，那么其他线程可以来完成这个耗时的操作；
• 比如网络请求、定时器，我们只需要在特性的时候执行应该有的回调即可；

事件循环

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

​ 简单地说，对于 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