摘要：本文通过联合官网文档MDN和其余博客深刻解析浏览器的事件循环机制，而NodeJS有另一套事件循环机制，不在本文探讨范畴中。process.nextTick和setImmediate是NodeJS的API，所以本文也不予探讨。

首先，先理解几个概念。

Javascript到底是单线程还是多线程语言？

Javascript是一门单线程语言。置信应该有不少敌人对于Javascript是单线程语言还有些疑难（题外话：之前在某次面试中遇到一个面试官，一来就是“咱们晓得JS是一门多线程语言。。。”巴拉巴拉，过后就把我给愣住了。），不是有Web Worker能够创立多个线程吗？答案就是，Javascript是单线程的，然而他的运行环境不是单线程。要如何了解这句话，首先得从Javascript运行环境比方浏览器的多线程说起。

浏览器通常蕴含以下线程：

  1. GUI渲染线程

    • 次要负责页面的渲染，解析HTML、CSS，构建DOM树，布局和绘制等。
    • 当界面须要重绘或者因为某种操作引发回流时，将执行该线程。
    • 该线程与JS引擎线程互斥，当执行JS引擎线程时，GUI渲染会被挂起。

  2. JS引擎线程

    • 该线程负责解决Javascript脚本，执行代码。
    • 负责执行待执行的事件，比方定时器计数完结，或者异步申请胜利并正确返回时，将顺次进入工作队列，期待JS引擎线程执行。
    • 该线程与GUI线程互斥，当JS线程执行Javascript脚本事件过长，将导致页面渲染的阻塞。

  3. 定时器触发线程

    • 负责执行异步定时器一类函数的线程，如：setTimeout，setInterval。
    • 主线程顺次执行代码时，遇到定时器会将定时器交给该线程解决，当计数结束后，事件触发线程会将计数结束的事件回调退出到工作队列，期待JS引擎线程执行。

  4. 事件触发线程

    • 次要负责将期待执行的事件回调交给JS引擎线程执行。

  5. 异步http申请线程

    • 负责执行异步申请一类函数的线程，如：Promise，axios，ajax等。
    • 主线程顺次执行代码时，遇到异步申请，会将函数交给该线程解决，当监听到状态码变更，如果有回调函数，事件触发线程会将回调函数退出到工作队列，期待JS引擎线程执行。

Web Worker是浏览器为Javascript提供的一个能够在浏览器后盾开启一个新的线程的API（相似下面说到浏览器的多个线程），使Javascript能够在浏览器环境中多线程运行，但这个多线程是指浏览器自身，是它在负责调度治理Javascript代码，让他们在失当机会执行。所以Javascript自身是不反对多线程的。

异步

Javascript的异步过程通常是这样的：

  1. 主线程发动一个异步申请，异步工作承受申请并告知主线程已收到（异步函数返回）；
  2. 主线程继续执行后续代码，同时异步操作开始执行；
  3. 异步操作执行实现后告诉主线程；
  4. 主线程收到告诉后，执行异步回调函数。

这个过程有个问题，异步工作各工作的执行工夫过程长短不同，执行实现的工夫点也不同，主线程如何调控异步工作呢？这就引入了音讯队列。

栈、堆、音讯队列

栈：函数调用造成的一个由若干帧组成的栈。

堆：对象被调配在堆中，堆是一个用来示意一大块（通常是非结构化的）内存区域。

音讯队列：一个Javascript运行时蕴含了一个待处理音讯的音讯队列。每一个音讯都关联着一个用来解决这个音讯的回调函数。在事件循环期间，运行时会从最先进入队列的音讯开始解决，被解决的音讯会被移出队列，并作为输出参数来调用与之关联的函数。而后事件循环在解决队列中的下一个音讯。

事件循环Event loop

理解了上述要点，当初回到主题事件循环。那么Event loop到底是什么呢？

Event loop是一个执行模型，在不同的中央有不同的实现。浏览器和NodeJS基于不同的技术实现了各自的Event loop。
当初明确为什么要把NodeJS排除在外了吧？同样网上很多Event loop的相干博文一来就是Javascript的Event loop，实际上说的都是浏览器的Event loop。
浏览器的Event loop是在Html5标准中定义的，大抵总结如下：

一个事件循环里有很多个工作队列（task queues）来自不同工作源，每一个工作队列里的工作（task）都是严格依照先进先出的程序执行的，然而不同工作队列的工作执行程序是不确定的，浏览器会本人调度不同工作队列。也有中央把task称之为macrotask（宏工作）。

标准中还提到了microtask（微工作）的概念，以下是标准论述的过程模型：

  1. 抉择以后要执行的工作队列，抉择一个最先进入工作队列的工作，如果没有工作能够抉择，则会跳转至microtask的执行步骤；
  2. 将事件循环的以后运行工作设置为已抉择的工作；
  3. 运行工作；
  4. 将事件循环的当前任务设置为null，将运行完的工作从工作队列中移除；
  5. microtask步骤：进入microtask检查点；
  6. 更新界面渲染；
  7. 返回第一步。

执行进入microtask检查点时，用户代理会执行以下步骤：

  1. 设置进入microtask检查点的标记为true；
  2. 当事件循环的微工作队列不为空时：抉择一个最先进入microtask队列的microtask，设置事件循环以后运行工作为此microtask；
  3. 运行microtask；
  4. 设置事件循环以后运行工作为null，将运行完结的microtask从microtask队列中移除；
  5. 对于相应事件循环的每个环境设置对象，告诉它们哪些promise为rejected；
  6. 清理indexedDB的事务；
  7. 设置进入microtask检查点的标记为false。

由上可总结为：在事件循环中，用户代理会一直从task队列中按程序取task执行，每执行完一个task都会查看microtask队列是否为空（执行完一个task的具体标记时函数执行栈为空），如果不为空则会一次性执行完所有microtask。而后再进入下一个循环去task队列中取下一个task执行。

task/macrotask（宏工作）

  • script（整体代码）
  • setTimeout
  • setInterval
  • I/O
  • UI rendering

microtask（微工作）

  • Promise.then catch finally
  • MutationObserver

来看一个例子：

console.log('script start');setTimeout(function() {  console.log('setTimeout');}, 0);Promise.resolve().then(function() {  console.log('promise1');}).then(function() {  console.log('promise2');});console.log('script end');

运行后果是：

script startscript endpromise1promise2setTimeout

那么问题来了，不是说每个事件循环开始会从task队列取最先进入的task执行，而后再执行所有microtask吗？为什么setTimeout是task却在Promise.then这个task的后面呢？反正我一开始是有这个纳闷的，很多文章都没有说分明这个具体执行的程序，大部分都是在形容标准的时候说的是“每个事件循环开始会从task队列中取一个task执行，而后再执行所有microtask”，然而也有局部文章说的是“每个事件循环开始都是先执行所有microtask”。通过自己多方查证，标准里的形容如上的确就是每个事件循环都是先执行task，那为什么下面例子外面体现进去的是先执行所有microtask呢？

script（整体代码）属于task。

来看一下下面例子的具体执行过程：

  1. 事件循环开始，task队列中只有一个script，抉择script作为事件循环的已抉择工作；
  2. script按程序执行，同步代码间接输入（script start、script end）；
  3. 遇到setTimeout，0ms后将回调函数放入task队列；
  4. 遇到Promise，将第一个then的回调函数放入microtask队列；
  5. 当所有script代码执行实现后，此时函数执行栈为空，开始查看microtask队列，队列只有第一个.then的回调函数，执行输入“promise1”，因为第一个.then返回的仍然是promise，所以第二个.then的回调会放入microtask队列继续执行，输入“promise2”；
  6. 此时microtask队列空了，进入下一个事件循环，查看task队列取出setTimeout回调函数，执行输入“setTimeout”，代码执行实现。

这样是不是分明了？所以实际上一开始执行script代码的时候就曾经开始事件循环了，这就解释了为什么如同每次都是先执行所有的microtask。同时，这个例子中还引申出一个要点：在执行microtask工作的时候，如果又产生了新的microtask，那么会持续增加到队列的开端，且也会在这个事件循环周期执行，直到microtask队列为空为止。