我所理解的event loop

灵魂三问

• JS为什么是单线程的
  • 我们都知道，JS是单线程的语言，那为什么呢？我的理解是JS设计之初就是为了在浏览器端完成DOM操作和一些简单交互的，既然涉及到DOM操作如果是多线程就会带来复杂的同步问题，比较极端的例子就是两个线程可能一个在删除某个DOM节点一个却在修改这个DOM节点，这是浏览器以哪个线程为准呢？
• 为什么需要异步
  • 如果没有异步，单线程的JS从上到下执行遇到一段代码需要执行比较久时就会阻塞页面的渲染，造成页面假死，这显然是一种很差的用户体验
• 单线程又是如何实现异步的呢
  • 单线程之所以能实现异步是因为在处理异步任务时并不是马上运行的，而是通过一个事件循环(event loop)机制来管理任务的执行。貌似是浏览器提供了这么一个管理任务的event loop线程，它来管理和负责向我们的主线程上输送需要执行的任务。所以理解了event loop的机制才能更好地理解JS的运行机制，理解JS的运行机制才能更准确地把握我们代码的运行规律。

由一个面试题引发的思考

首先来看一道考察JS执行机制的面试题，原题是今日头条的前端面试题，我稍微进行了一点改造：

async function async1() {
  console.log( 'async1 start' )
  await async2()
  console.log( 'async1 end' )
}

async function async2() {
  new Promise( function ( resolve ) {
    console.log( '11' )
    resolve();
  }).then( function () {
    console.log( '22' )
  })
}

console.log( 'script start' )

setTimeout( function () {
  console.log( 'setTimeout' )
}, 0 )

async1();

new Promise( function ( resolve ) {
  console.log( 'promise1' )
  resolve();
}).then( function () {
  console.log( 'promise2' )
})

console.log( 'script end' )

看完之后如果不在浏览器端运行一下你能有自己的答案吗，并且能自圆其说吗？得到答案都不难，放在浏览器里自然就有了输出：

script start
async1 start
11
promise1
script end
22
promise2
async1 end
setTimeout

因为题目是千变万化的，日常开发中的情况也是多种多样的，正确理解了其中的执行规律才能更好地开发，当然如果你得到的结果是一样的并且能够自圆其说那也就没必要看下去了，如果你还对这个结果有点懵那就听听我的理解吧。

微任务与宏任务

事实上，我们的JS代码用同步和异步这两种划分方式来决定执行的先后顺序显然是不够的，从而有了另一种划分方式，具体谁提出来的我就没考证了，大体上大家是这样分的：

• macro-task(宏任务)：整体代码script，setTimeout，setInterval
• micro-task(微任务)：Promise的then回调，process.nextTick(Node)

因为我们上面的面试题是前端面试题，所以我们讨论的都是浏览器环境下的表现，node环境下的event loop貌似有些不一样，这里就不讨论了。

event loop的运行机制

既然前端谈到了JS是单线程的，同时只能处理一个任务，而我们又将各种各样的任务分为了宏任务和微任务，那到底哪种任务先执行了，这个运行逻辑就是event loop的判断逻辑。

先说说我的理解，再来印证上面代码的运行顺序：

• 一段代码执行时先执行宏任务中的同步代码
• 如果遇到像setTimeout这类宏任务就会把代码方式【宏任务队列】中
• 如果遇到像Promise.then()这类微任务会放入【微任务队列】
• 在本轮宏任务中的同步代码执行完之后就会依次执行本轮微任务队列中的代码，然后执行下一轮中的宏任务代码

说回上面的面试题，我们模拟event loop来首先给他们归个队

• 首先遇到了console.log( ‘script start’ )，直接打印
• 然后遇到了setTimeout这个宏任务，就被推到宏任务队列中
• 然后是async1()，直接打印同步代码console.log( ‘async1 start’ )
• 关于await async2()，实际上是从右到左先执行了async2()里的代码，然后遇到await从而交出线程的控制权的，async2()执行之后先打印了11，console.log( ‘22’ )被推入了微任务队列
• 接着执行Promise中的同步代码console.log( ‘promise1’ )，然后将console.log( ‘promise2’ )推入微任务队列
• 接着打印同步代码console.log( ‘script end’ )，到此，所有同步代码执行完毕
• 接下来就要执行本轮代码中的微任务队列了，所以先打印22，再打印promise2
• 至此，await等待的async2()执行完了，可以执行await下面的代码了，所以接下来打印async1 end
• 最后，就是执行下一轮event loop中的宏任务setTimeout，最后打印setTimeout

单独说一下async和await

async本质上是加上了Generator函数并且内置了执行器的一个语法糖，并且async函数返回的是Promise对象。唯一需要注意的是await后面无论接的是同步代码还是异步代码都要等他们执行完毕才能执行await结果之后的代码。并且经过验证，当遇到await语句时是从右到左先执行的await后面的代码，然后才交出线程的控制权直到await等待的结果运行完毕。

总结

总体上，算是能对上面那个题目的执行过程有了一个能自圆其说的解释，只是吧，为什么规则是这样的呢？这些规则怎么证伪呢？这是我查资料的时候最纠结的问题。后来跟同事交流了之后吧，觉得也没必要纠结，毕竟最终的解释器是C写的，不懂规则可以去看源码啊，可是我看不懂啊，哈哈。。。所以，既然大家大部分人都是这么说，也能说得通，暂且先记着吧，至少，还是能够解释日常中形形色色代码的运行规律的。

看了几篇不同观点的文章之后重新梳理一下event loop的顺序：

• 先执行宏任务中的同步代码
• 执行栈清空之后查询任务队列
• 如果任务队列中有微任务，先执行
• 执行完了微任务之后开始下一轮event loop，执行队列中宏任务的异步代码

参考文章中有几篇文章比我讲的生动一些，没看懂的可以参考一下，我主要是梳理一下自己的理解，有不同想法的欢迎交流。

参考文章

• 微任务、宏任务与Event-Loop
• 8张图帮你一步步看清 async/await 和 promise 的执行顺序
• 10分钟理解JS引擎的执行机制
• 理解 JavaScript 的async/await
• 浅谈js运行机制(线程）
• 从setTimeout-setInterval看JS线程