JavaScript 事件循环

JavaScript 事件循环

• • 事件循环
  • 任务队列
  • • async/await 又是如何处理的呢 ？
    • 定时器问题
    • 阻塞还是非阻塞
    • 实际应用案例
    • • 拆分 CPU 过载任务
      • 进度指示
      • 在事件之后做一些事情

事件循环

事件循环 的概念非常简单。它是一个在JavaScript 引擎等待任务，执行任务和进入休眠状态等待更多任务这几个状态之间转换的无限循环。

引擎的一般算法：

1. 当有任务时：从最先进入的任务开始执行。
2. 休眠直到出现任务，然后转到第 1 步。

当我们浏览一个网页时就是上述这种形式。JavaScript引擎大多数时候不执行任何操作，它仅在脚本/处理程序/事件激活时执行。

任务示例：

• 当外部脚本 <script src="..."> 加载完成时，任务就是执行它。
• 当用户移动鼠标时，任务就是派生出 mousemove 事件和执行处理程序。
• 当安排的（scheduled）setTimeout 时间到达时，任务就是执行其回调。
• ……

设置任务 —— 引擎处理它们 —— 然后等待更多任务（即休眠，几乎不消耗 CPU 资源）。

一个任务到来时，引擎可能正处于繁忙状态，那么这个任务就会被排入队列。

多个任务组成了一个队列，即所谓的“宏任务队列”（v8 术语）：

例如，当引擎正在忙于执行一段 script 时，用户可能会移动鼠标而产生 mousemove 事件，setTimeout 或许也刚好到期，以及其他任务，这些任务组成了一个队列。

队列中的任务基于“先进先出”的原则执行。当浏览器引擎执行完 script 后，它会处理 mousemove 事件，然后处理 setTimeout 处理程序，依此类推。

例如：

引擎执行任务时永远不会进行渲染（render）。如果任务执行需要很长一段时间也没关系。仅在任务完成后才会绘制对 DOM 的更改。

如果一项任务执行花费的时间过长，浏览器将无法执行其他任务，例如处理用户事件。因此，在一定时间后，浏览器会抛出一个如“页面未响应”之类的警报，建议你终止这个任务。这种情况常发生在有大量复杂的计算或导致死循环的程序错误时。

任务队列

JavaScript 是有两个任务队列的，一个叫做 Macrotask Queue(Task Queue) 宏任务, 一个叫做 Microtask Queue 微任务

Macrotask 常见的任务：

• setTimeout
• setInterval
• setImmediate
• I/O
• 用户交互操作，UI渲染

Microtask 常见的任务：

• Promise(重点)
• process.nextTick(nodejs)
• Object.observe(不推荐使用)

那么，两者有什么具体的区别呢？或者说，如果两种任务同时出现的话，应该选择哪一个呢？

每个宏任务之后，引擎会立即执行微任务队列中的所有任务，然后再执行其他的宏任务，或渲染，或进行其他任何操作。

其实事件循环执行流程如下:

1. 检查 Macrotask队列是否为空,若不为空，则进行下一步，若为空，则跳到3
2. 从 Macrotask 队列中取队首(在队列时间最长)的任务进去执行栈中执行(仅仅一个)，执行完后进入下一步
3. 检查 Microtask 队列是否为空，若不为空，则进入下一步，否则，跳到1（开始新的事件循环）
4. 从 Microtask 队列中取队首(在队列时间最长)的任务进去事件队列执行,执行完后，跳到3 其中，在执行代码过程中新增的microtask任务会在当前事件循环周期内执行，而新增的macrotask任务只能等到下一个事件循环才能执行了。

简而言之，一次事件循环只执行处于 Macrotask 队首的任务，执行完成后，立即执行 Microtask 队列中的所有任务。

我们先来看一段代码:

 console.log(1)
setTimeout(function() {
  //settimeout1
  console.log(2)
}, 0);
const intervalId = setInterval(function() {
  //setinterval1
  console.log(3)
}, 0)
setTimeout(function() {
  //settimeout2
  console.log(10)
  new Promise(function(resolve) {
    //promise1
    console.log(11)
    resolve()
  })
  .then(function() {
    console.log(12)
  })
  .then(function() {
    console.log(13)
    clearInterval(intervalId)
  })
}, 0);

//promise2
Promise.resolve()
  .then(function() {
    console.log(7)
  })
  .then(function() {
    console.log(8)
  })
console.log(9)

你觉得结果应该是什么呢?

在chrome控制台输出的结果如下:

1
9
7
8
2
3
10
11
12
13

在上面的例子中

• 第一次事件循环:

1. console.log(1)被执行，输出1
2. settimeout1执行，加入macrotask队列
3. setinterval1执行，加入macrotask队列
4. settimeout2执行，加入macrotask队列
5. promise2执行，它的两个then函数加入microtask队列
6. console.log(9)执行，输出9
7. 根据事件循环的定义，接下来会执行新增的microtask任务，按照进入队列的顺序，执行console.log(7)和console.log(8),输出7和8 microtask队列为空，回到第一步，进入下一个事件循环，此时macrotask队列为: settimeout1,setinterval1,settimeout2

• 第二次事件循环:

从macrotask队列里取位于队首的任务(settimeout1)并执行，输出2 microtask队列为空，回到第一步，进入下一个事件循环，此时macrotask队列为: setinterval1,settimeout2

• 第三次事件循环:

从macrotask队列里取位于队首的任务(setinterval1)并执行，输出3,然后又将新生成的setinterval1加入macrotask队列 microtask队列为空，回到第一步，进入下一个事件循环，此时macrotask队列为: settimeout2,setinterval1

• 第四次事件循环:

从macrotask队列里取位于队首的任务(settimeout2)并执行,输出10，并且执行new Promise内的函数(new Promise内的函数是同步操作，并不是异步操作),输出11，并且将它的两个then函数加入microtask队列 从microtask队列中，取队首的任务执行，直到为空为止。因此，两个新增的microtask任务按顺序执行，输出12和13，并且将setinterval1清空。

此时，microtask队列和macrotask队列都为空，浏览器会一直检查队列是否为空，等待新的任务加入队列。在这里，大家可以会想，在第一次循环中，为什么不是macrotask先执行？因为按照流程的话，不应该是先检查macrotask队列是否为空，再检查microtask队列吗？

原因：因为一开始js主线程中跑的任务就是macrotask任务，而根据事件循环的流程，一次事件循环只会执行一个macrotask任务，因此，执行完主线程的代码后，它就去从microtask队列里取队首任务来执行。

**注意：**由于在执行microtask任务的时候，只有当microtask队列为空的时候，它才会进入下一个事件循环，因此，如果它源源不断地产生新的microtask任务，就会导致主线程一直在执行microtask任务，而没有办法执行macrotask任务，这样我们就无法进行UI渲染/IO操作/ajax请求了，因此，我们应该避免这种情况发生。在nodejs里的process.nexttick里，就可以设置最大的调用次数，以此来防止阻塞主线程。

async/await 又是如何处理的呢 ？

大家看看这段代码在浏览器上的输出是什么？

async function async1() {
    console.log('async1 start');
    await async2();
    console.log('async1 end');
}
async function async2() {
    console.log('async2');
}
async1();
new Promise(function(resolve) {
    console.log('promise1');
    resolve();
}).then(function() {
    console.log('promise2');
});
console.log('script end');

这段代码多了 async/await 只要我们弄懂这个异步处理的原理，就可以知道它们的执行顺序了。

async/await：这哥俩个其实是 Promise 和 Generator 的语法糖，所以我们把它们转成我们熟悉的 Promise

async function async1() {
    console.log('async1 start');
    await async2();
    console.log('async1 end');
}
// 其实就是
async function async1() {
    console.log('async1 start');
    Promise.resolve(async2()).then(()=>console.log('async1 end'))
}

那我们再看看转换后的整体代码

async function async1() {
    console.log('async1 start');
    Promise.resolve(async2()).then(()=>console.log('async1 end'))
}
async function async2() {
    console.log('async2');
}
async1();
new Promise(function(resolve) {
    console.log('promise1');
    resolve();
}).then(function() {
    console.log('promise2');
});
console.log('script end');

这下就很明白了吧，输出的结果如下:

/**
 * async1 start
 * async2
 * promise1
 * script end
 * async1 end
 * promise2
 * */

定时器问题

以此，我们来引入一个新的问题，定时器的问题。定时器是否是真实可靠的呢？比如我执行一个命令:setTimeout(task, 100),他是否就能准确的在100毫秒后执行呢？其实根据以上的讨论，我们就可以得知，这是不可能的。

我们看这个栗子

const s = new Date().getSeconds();

setTimeout(function() {
  // 输出 "2"，表示回调函数并没有在 500 毫秒之后立即执行
  console.log("Ran after " + (new Date().getSeconds() - s) + " seconds");
}, 500);

while(true) {
  if(new Date().getSeconds() - s >= 2) {
    console.log("Good, looped for 2 seconds");
    break;
  }
}

如果不知道事件循环机制，那么想当然就认为 setTimeout 中的事件会在 500 毫秒后执行，但实际上是在 2秒后才执行，原因大家应该都知道了，主线程一直有任务在执行，直到2秒后，主线程中的任务才执行完成，这才去执行macrotask中的 setTimeout 回调任务。

因为你执行 setTimeout(task,100) 后，其实只是确保这个任务，会在100毫秒后进入macrotask队列，但并不意味着他能立刻运行，可能当前主线程正在进行一个耗时的操作，也可能目前microtask队列有很多个任务，所以用setTimeout 作为倒计时其实并不会保证准确。

阻塞还是非阻塞

关于 js 阻塞还是非阻塞的问题我们先理解下同步、异步、阻塞还是非阻塞的解释，在网上看到一段描述的非常好，引用下

我要看足球比赛，但是妈妈叫我烧水，电视机在客厅，烧水要在厨房。家里有2个水壶，一个是普通的水壶，另一个是水开了会叫的那种水壶。我可以：

1. 用普通的水壶烧，人在边上看着，水开了再去看球。**（同步，阻塞）**这个是常规做法，但是我看球不爽了。
2. 用普通水壶烧，人去看球，隔几分钟去厨房看看。**（同步，非阻塞）**这个又大问题，万一在我离开的几分钟水开了，我就麻烦了。
3. 用会叫的水壶，人在边上看着。**（异步，阻塞）**这个没有问题，但是我太傻了。
4. 用会叫的水壶，人去看球，听见水壶叫了再去看。**（异步，非阻塞）**这个应该是最好的。

等着看球的我：阻塞

看着电视的我：非阻塞

普通水壶：同步

会叫的水壶：异步

所以，异步往往配合非阻塞，才能发挥出威力。

js 核心还是同步阻塞的，比如看这段代码

while (true) {
    if (new Date().getSeconds() - s >= 2) {
        console.log("Good, looped for 2 seconds");
        break;
    }
}
console.log('end')

console.log('end') 的执行需要在while 循环结束后才能执行，如果循环一直没结束，那么线程就被阻塞了。

而对于js 的异步事件，因为有事件循环机制，异步事件就是由事件驱动异步非阻塞的，上面的栗子已经很好证明了。所以 nodejs适合处理大并发，因为有事件循环和任务队列机制，异步操作都由工作进程处理（libuv），js 主线程可以继续处理新的请求。缺点也很明显，因为是单线程，所以对计算密集型的就会比较吃力，不过可以通过集群的模式解决这个问题。

实际应用案例

拆分 CPU 过载任务

假设我们有一个 CPU 过载任务。

例如，语法高亮（用来给本页面中的示例代码着色）是相当耗费CPU资源的任务。为了高亮显示代码，它执行分析，创建很多着了色的元素，然后将它们添加到文档中 —— 对于文本量大的文档来说，需要耗费很长时间。

当引擎忙于语法高亮时，它就无法处理其他 DOM 相关的工作，例如处理用户事件等。它甚至可能会导致浏览器“中断（hiccup）”甚至“挂起（hang）”一段时间，这是不可接受的。

我们可以通过将大任务拆分成多个小任务来避免这个问题。高亮显示前 100 行，然后使用 setTimeout（延时参数为 0）来安排（schedule）后100行的高亮显示，依此类推。

为了演示这种方法，简单起见，让我们写一个从 1 数到 1000000000 的函数，而不写文本高亮。

如果你运行下面这段代码，你会看到引擎会“挂起”一段时间。对于服务端JS 来说这显而易见，并且如果你在浏览器中运行它，尝试点击页面上其他按钮时，你会发现在计数结束之前不会处理其他事件。

let i = 0;

let start = Date.now();

function count() {

  // 做一个繁重的任务
  for (let j = 0; j < 1e9; j++) {
    i++;
  }

  alert("Done in " + (Date.now() - start) + 'ms');
}

count();

浏览器甚至可能会显示一个“脚本执行时间过长”的警告。

让我们使用嵌套的 setTimeout 调用来拆分这个任务：

let i = 0;

let start = Date.now();

function count() {

  // 做繁重的任务的一部分 (*)
  do {
    i++;
  } while (i % 1e6 != 0);

  if (i == 1e9) {
    alert("Done in " + (Date.now() - start) + 'ms');
  } else {
    setTimeout(count); // 安排（schedule）新的调用 (**)
  }

}

count();

现在，浏览器界面在“计数”过程中可以正常使用。

单次执行 count 会完成工作 (*) 的一部分，然后根据需要重新安排（schedule）自身的执行 (**)：

1. 首先执行计数：i=1...1000000。
2. 然后执行计数：i=1000001..2000000。
3. ……以此类推。

现在，如果在引擎忙于执行第一部分时出现了一个新的副任务（例如 onclick 事件），则该任务会被排入队列，然后在第一部分执行结束时，并在下一部分开始执行前，会执行该副任务。周期性地在两次 count 执行期间返回事件循环，这为JavaScript引擎提供了足够的“空气”来执行其他操作，以响应其他的用户行为。

值得注意的是这两种变体 —— 是否使用了 setTimeout 对任务进行拆分 —— 在执行速度上是相当的。在执行计数的总耗时上没有多少差异。

为了使两者耗时更接近，让我们来做一个改进。

我们将要把调度（scheduling）移动到 count() 的开头：

let i = 0;

let start = Date.now();

function count() {

  // 将调度（scheduling）移动到开头
  if (i < 1e9 - 1e6) {
    setTimeout(count); // 安排（schedule）新的调用
  }

  do {
    i++;
  } while (i % 1e6 != 0);

  if (i == 1e9) {
    alert("Done in " + (Date.now() - start) + 'ms');
  }

}

count();

现在，当我们开始调用 count() 时，会看到我们需要对 count() 进行更多调用，我们就会在工作前立即安排（schedule）它。

如果你运行它，你很容易注意到它花费的时间明显减少了。

为什么？

这很简单：你应该还记得，多个嵌套的 setTimeout 调用在浏览器中的最小延迟为 4ms。即使我们设置了 0，但还是 4ms（或者更久一些）。所以我们安排（schedule）得越早，运行速度也就越快。

最后，我们将一个繁重的任务拆分成了几部分，现在它不会阻塞用户界面了。而且其总耗时并不会长很多。

进度指示

对浏览器脚本中的过载型任务进行拆分的另一个好处是，我们可以显示进度指示。

正如前面所提到的，仅在当前运行的任务完成后，才会对 DOM 中的更改进行绘制，无论这个任务运行花费了多长时间。

从一方面讲，这非常好，因为我们的函数可能会创建很多元素，将它们一个接一个地插入到文档中，并更改其样式 —— 访问者不会看到任何未完成的“中间态”内容。很重要，对吧？

这是一个示例，对 i 的更改在该函数完成前不会显示出来，所以我们将只会看到最后的值：

<div id="progress"></div>

<script>

  function count() {
    for (let i = 0; i < 1e6; i++) {
      i++;
      progress.innerHTML = i;
    }
  }

  count();
</script>

……但是我们也可能想在任务执行期间展示一些东西，例如进度条。

如果我们使用 setTimeout 将繁重的任务拆分成几部分，那么变化就会被在它们之间绘制出来。

这看起来更好看：

<div id="progress"></div>

<script>
  let i = 0;

  function count() {

    // 做繁重的任务的一部分 (*)
    do {
      i++;
      progress.innerHTML = i;
    } while (i % 1e3 != 0);

    if (i < 1e7) {
      setTimeout(count);
    }

  }

  count();
</script>

现在 div 显示了 i 的值的增长，这就是进度条的一种。

在事件之后做一些事情

在事件处理程序中，我们可能会决定推迟某些行为，直到事件冒泡并在所有级别上得到处理后。我们可以通过将该代码包装到零延迟的 setTimeout 中来做到这一点。

在 创建自定义事件[1] 一章中，我们看到过这样一个例子：自定义事件 menu-open 被在 setTimeout 中分派（dispatched），所以它在 click 事件被处理完成之后发生。

menu.onclick = function() {
  // ...

  // 创建一个具有被点击的菜单项的数据的自定义事件
  let customEvent = new CustomEvent("menu-open", {
    bubbles: true
  });

  // 异步分派（dispatch）自定义事件
  setTimeout(() => menu.dispatchEvent(customEvent));
};