壹 ❀ 引
通过结果倒推过程是我们常用的思考模式，我在上一篇学习promise笔记中，有少量关于promise执行顺序的例子，通过倒推，我成功让自己对于js执行机制的理解一塌糊涂，js事件机制，事件循环是面试常考的点，弄懂它们是贼有必要的。
回顾下我学习promise的心理历程：
let p = Promise.resolve(1);
p.then(resp => console.log(resp));
console.log(2);
//
//
哦，原来如此，同步代码会先执行，先输出2，所以then回调是异步。
let p1 = Promise.resolve(1);
p1.then(resp => console.log(resp));
let p2 = Promise.resolve(2);
p2.then(resp => console.log(resp));
//
//
哦！多个异步，先注册的回调先执行，原来如此。
setTimeout(() => console.log(2),0);
let p1 = Promise.resolve(1);
p1.then(resp => console.log(resp));
//
//
嗯？？？？不是先注册的异步先执行？为啥这里先输出1，promise学习下来，成功让自己懵逼。
理解JS执行机制是很重要的，它会让你的代码调试更符合自己的预期，其次对于面试也非常有帮助。
介绍js执行机制的文章挺多了，这里只是做个个人思路的整理，那么开始。
贰 ❀ JavaScript中的同步异步
JavaScript是一门单线程非阻塞语言，在同一时间只能专心做一件事，如果前面的事情没做，后面的事情就得耐心的等着，这就是所谓的同步。
你会想，为什么要同步？
JavaScript本身是一门浏览器脚本语言，更多负责用户的交互，dom操作之类；假设JS并非单线程，我让两个行为同时操作一个dom对象，那岂不是乱套了。想想我们排队取餐吃饭，如果不排队，往往容易引发争吵，编程也是现实行为的抽象。
也许你会说，不是有web worker吗，但web worker属于浏览器的解决方法，并非JavaScript；浏览器虽然可以开多个线程，但每个线程仍然是单线程，而且也不被允许操作dom，这依旧没改变JS是单线程语言的事实。
let funA = () => {
let NUM = 10000;
while (NUM) {
NUM--;
};
console.log(1);
};
let funB = () => console.log(2);
funA(); //
funB(); //
在上述代码中，让10000进行自减如果让我们脑补这个过程是很费时的，但是对于强大的js引擎来说并不是事，也要不了太多时间；
可在开发中我们得处理大量的网络请求，我们知道请求可能存在延迟，服务器查询也得耗时，一次请求受诸多不确定因素影响，我们不可能让一次网络请求堵塞后面的程序。
也正因如此异步诞生了，对于不确定的网络请求，定时器之类，咱先备注一下有这些需要处理，就接着去忙同步的事情了，等手头上同步的处理完了，再来解决先前备注的异步事件。
想想我们排队取餐吃饭，前面的哥们大声说道，牛肉面不要面只要牛肉，多葱多蒜少辣不吃香菜半小时后来取，老板也不会等他半小时把面取了再做后面顾客的生意，那真要这样，店子早倒闭了。
那么说完同步异步，我们大概有了个抽象的概念，js会先执行同步，万一遇到异步，就先备注下有这个异步，等同步跑完了咱再来处理异步的后续操作，那么站在js角度这个过程是什么样的，我们接着说。
叁 ❀ 执行栈与任务队列
我们都知道，当一个方法被调用时，JavaScript会生成一个属于此方法的执行环境，也叫执行上下文，这个上下文中存放着方法依赖的参数，变量以及作用域等等。
什么是执行栈呢？当调用一个方法A时，这个方法可能也会调用另一个方法B，B还可能调用方法C，而JS只能同时一件事，所以方法B、C没执行完之前，方法A也不能被释放，那总得找个地方把这些方法按顺序存一存吧，存放的地方就是执行栈。
关于执行上下文，执行栈，具体可以阅读这篇文章 一篇文章看懂JS执行上下文 这里我们就只做简单阐述了。
执行栈是存放同步方法调用的地方，遵从先进后出的规则：
let A = () => {
B()
console.log(1);
};
let B = () => {
C()
console.log(2);
};
let C = () => {
console.log(3);
};
A();//3 2 1
上述代码站在执行机制角度来看，是这样的，你应该也能理解递归处理不好陷入死循环后爆栈是个什么情况了：
凭直觉来想，异步任务不可能直接在执行栈中执行，不然绝对存在堵塞的问题，那先存放在哪呢？放在了任务队列中。
那么到这里我们又有了一个模糊的概念，同步任务与异步任务存放的地方不同，有个问题，JavaScript怎么知道什么时候去执行异步任务呢？那就不得不说事件循环。
肆 ❀ 事件循环 (Event Loop)
图片来源
当一个任务被执行，js会判断是否为同步任务，如果是同步，压入主线程立即执行；但如果是异步任务，移到异步处理模块(Task Table)，当异步任务有了结果，就将异步任务的回调函数注入到任务队列中等待。
当主线程的同步任务执行完毕执行栈为空，js引擎就会读取任务队列中的第一个任务加入到执行栈执行，当此任务完成，继续重复此类操作，这也就是事件循环了，任务队列满足先进先出的特性。
那么到这里，我们知道js引擎会利用事情循环机制来处理同步异步问题；那么问题又来了，还记得文章开头第三个例子吗，定时器和promise都是异步，为什么后面的promise反而比前面的定时器先执行，难道异步任务也有自己的先后顺序？这里就得引出宏任务与微任务了。
伍 ❀ 宏任务与微任务
我们先对宏任务微任务做个大概分类：
macro-task(宏任务)：script环境 setTimeout、setInterval、I/O、事件、postMessage、 MessageChannel、setImmediate (Node.js)
micro-task(微任务)：Promise，process.nextTick，MutaionObserver
很多面孔没见过，没关系，好歹我们知道了定时器是宏任务，new Promise是微任务。我把上面的例子搬下来：
setTimeout(() => console.log('我第一'), 1000);
let p1 = Promise.resolve('我第二');
p1.then(resp => console.log(resp));
//我第二
//我第一
明明是定时器先进的异步处理模块，结果promise.then还要早于定时器先执行，为什么呢？
这是因为，异步任务中又分为宏任务与微任务两种，当执行栈为空，JS引擎会优先处理微任务队列的任务，等到微任务队列处理完成，才会处理宏任务队列的任务。
setTimeout(() => console.log('我第一'), 2000);
let p1 = Promise.resolve('我第二');
p1.then(resp => console.log(resp));
setTimeout(() => console.log('我第三'), 1000);
let p2 = Promise.resolve('我第四');
p2.then(resp => console.log(resp));
//我第二
//我第四
//我第三
//我第一
上述代码中，不管你异步代码是怎么个顺序，我们可以明确的是微任务优先级总是高于宏任务。
但需要注意的是，script整体环境都是一个宏任务，所以微任务由宏任务执行过程中产生，除去同步代码执行完毕后，微任务执行优先级总是要优于剩余的异步宏任务。这里引用一张图：
图片来源
上图中，宏任务运行过程中可能会产生微任务，若有微任务，执行所有微任务(前期是同步代码跑完了)，微任务优先级始终高于宏任务（抛开同步代码）。
对于任务队列具有先进先出的特性，你肯定要喷我了，如果先进先出上述代码中等待2000ms的定时器比等待1000ms的定时器晚执行？那这里就得聊聊定时器时间的具体意义了。
陆 ❀ 有趣的定时器
定期器分为一次性定时器setTimeout与周期性定时器setInterval，前者是等待N秒之后执行回调一次没了，后者是每隔N秒执行回调一次。
有这么一个定时器：
setTimeout(() => console.log('我第一'), 3000);
站在宏观思想上理解，这行代码的意思是这个定时器将在三秒后触发，但站在微观的角度上，3000ms并不代表执行时间，而是将回调函数加入任务队列的时间，这也是为何存在定时器执行与所设置等待时间不符的问题所在。
setTimeout(() => console.log('我第一'), 3000);
setTimeout(() => console.log('我第二'), 3000);
你猜这两个定时器怎么执行？先等三秒打印“我第一”，再等三秒打印“我第二”吗？其实不是，真正执行是是等待三秒后几乎无间隔的同时打印2个结果。
我们可以脑补下执行顺序，首先遇到第一个定时器，告诉异步处理模块，等待三秒后将回调加入任务队列，然后又调用了第二个定时器，同样是3秒后将回调加入任务队列。
等到执行栈为空，去任务队列拿任务，执行第一个console，这要不了多久，于是几乎无时差的又去任务队列拿第二个任务，这也导致了为什么2次输出几乎在同时进行。
两个定时器等待时间相同，但第一个定时器回调还是先进入任务队列，所以先触发，这也印证了任务队列先进先出的规则。
所以当我们使用周期定时器setInterval时，也会遇到执行间隔与所设时间不符的情况，比如前面有个贼复杂的操作，导致周期定时器按时间不停给任务队列加入回调，等到前面任务跑完，这时你会发现前面所积累的回调像憋久了一样一下全部一起执行了。
看到这大家应该对于JS执行机制有一定了解了，不妨阅读下博主 从一道看似简单的面试题重新理解JS执行机制与定时器 这篇文章，通过面试题来巩固下自己的理解程度。
如果大家对JS执行上下文有兴趣，欢迎阅读博主 一篇文章看懂JS执行上下文这篇文章，一定会有所收获。
那么本文到这里就结束了。
柒 ❀ 参考
最后一次搞懂 Event Loop
这一次，彻底弄懂 JavaScript 执行机制
详解JavaScript中的Event Loop（事件循环）机制
