一、是什么
JavaScript 在设计之初便是单线程，即指程序运行时，只有一个线程存在，同一时间只能做一件事
为什么要这么设计，跟JavaScript的应用场景有关
JavaScript 初期作为一门浏览器脚本语言，通常用于操作 DOM ，如果是多线程，一个线程进行了删除 DOM ，另一个添加 DOM，此时浏览器该如何处理？
为了解决单线程运行阻塞问题，JavaScript用到了计算机系统的一种运行机制，这种机制就叫做事件循环（Event Loop）
事件循环（Event Loop）
在JavaScript中，所有的任务都可以分为
同步任务：立即执行的任务，同步任务一般会直接进入到主线程中执行
异步任务：异步执行的任务，比如ajax网络请求，setTimeout定时函数等
同步任务与异步任务的运行流程图如下：
从上面我们可以看到，同步任务进入主线程，即主执行栈，异步任务进入任务队列，主线程内的任务执行完毕为空，会去任务队列读取对应的任务，推入主线程执行。上述过程的不断重复就是事件循环
二、宏任务与微任务
如果将任务划分为同步任务和异步任务并不是那么的准确，举个例子：
console.log(1) setTimeout(()=>{ console.log(2) }, 0) new Promise((resolve, reject)=>{ console.log('new Promise') resolve() }).then(()=>{ console.log('then') }) console.log(3)
如果按照上面流程图来分析代码，我们会得到下面的执行步骤：
- console.log(1)，同步任务，主线程中执行
- setTimeout() ，异步任务，放到 Event Table，0 毫秒后console.log(2)回调推入 Event Queue 中
- new Promise ，同步任务，主线程直接执行
- .then ，异步任务，放到 Event Table
- console.log(3)，同步任务，主线程执行
所以按照分析，它的结果应该是 1 => ‘new Promise’ => 3 => 2 => ‘then’
但是实际结果是：1=>‘new Promise’=> 3 => ‘then’ => 2
出现分歧的原因在于异步任务执行顺序，事件队列其实是一个“先进先出”的数据结构，排在前面的事件会优先被主线程读取
例子中 setTimeout回调事件是先进入队列中的，按理说应该先于 .then 中的执行，但是结果却偏偏相反
原因在于异步任务还可以细分为微任务与宏任务
微任务
一个需要异步执行的函数，执行时机是在主函数执行结束之后、当前宏任务结束之前
常见的微任务有：
- Promise.then
- MutaionObserver
- Object.observe（已废弃；Proxy 对象替代）
- process.nextTick（Node.js）
宏任务
宏任务的时间粒度比较大，执行的时间间隔是不能精确控制的，对一些高实时性的需求就不太符合
常见的宏任务有：
- script (可以理解为外层同步代码)
- setTimeout/setInterval
- UI rendering/UI事件
- postMessage、MessageChannel
- setImmediate、I/O（Node.js）
按照这个流程，它的执行机制是：
一个宏任务，如果遇到微任务就将它放到微任务的事件队列中
当前宏任务执行完成后，会查看微任务的事件队列，然后将里面的所有微任务依次执行完
三、async与await
async 是异步的意思，await则可以理解为等待
放到一起可以理解async就是用来声明一个异步方法，而 await是用来等待异步方法执行
async
async函数返回一个promise对象，下面两种方法是等效的
function f() { return Promise.resolve('TEST'); } // asyncF is equivalent to f! async function asyncF() { return 'TEST'; }
不管await后面跟着的是什么，await都会阻塞后面的代码
async function fn1 (){ console.log(1) await fn2() console.log(2) // 阻塞 } async function fn2 (){ console.log('fn2') } fn1() console.log(3)
上面的例子中，await 会阻塞下面的代码（即加入微任务队列），先执行 async外面的同步代码，同步代码执行完，再回到 async 函数中，再执行之前阻塞的代码
所以上述输出结果为：1，fn2，3，2
