这篇文章我们来了解和简单的分析一下浏览器和node环境中的event loop（事件循环）。
有些小伙伴可能听说过eventloop这个名词，但是没有了解过，接下来我们就来了解一下。
我们先来看一组代码。
来猜一下执行结果
我们来捋一下。代码的执行肯定是由上自下而我们这里有两个定时器setTimeout，所以我们第一次执行的结果肯定是在控制台打印出1->2->5，这个应该是毋庸置疑的,然后呢开始执行我们的setTimeout。
这里需要注意一下这两个setTimeout肯定也是先后顺序执行的，我们应该知道在浏览器的执行过程中。如果不写setTimeout的第二个参数那么这个setTimeout的延时大约是4ms（毫秒）(我记得好像是。。).
所以当我们依次console出1、2、5之后我们的setTimeout执行，控制台会打印 3->4。
那么问题就来了，为什么会输出3->4?为什么不是3-6-4-7或者3-4-7-6??
留个悬念。。我们直接来看这段代码的运行结果。
node环境
浏览器环境
我们可以看到上面的代码不管是node环境还是浏览器环境下输出的结果是相同的，都是1-2-5-3-4-6-7.
我们来分析一下，当代码执行完console之后，先调用了第一个setTimeout然后调用了第二个setTimeout。
在之后又调用了第一个setTimeout中的setTimeout。最后执行的是第二个setTimeout中的setTimeout。
别急，我们再来看一组代码。
我们来看下面的代码。
来猜一下执行结果
我们再来捋一捋。。
首先我们应该肯定的是先打印1然后第一个setTimeout中打印出2 。这应该是肯定的。
然后问题又来了。。我们知道Promise是一个异步的方法对吧。那这里应该是先打印Promise中的then方法中的log还是下一个setTimeout中的log呢？
我们分别来看一下，代码在node环境和浏览器环境下的执行结果。
node环境
浏览器环境
我们应该注意到了。！这一次浏览器中的log和node环境下的log打印的顺序是不一样的。
为什么？
这就要说到我们的event loop了。我们接下来就来说一说这个东西。
我们先来了解一下javascript的一个特点。
JavaScript语言的一大特点就是单线程，也就是说，同一个时间只能做一件事。那么有些小伙伴就要问了，为什么js不能是多线程的？这样效率不是会更高吗？
我曾经看过阮一峰老师的event loop（JavaScript 运行机制详解：再谈Event Loop），里面是这样解释的。
JavaScript的单线程，与它的用途有关。作为浏览器脚本语言，JavaScript的主要用途是与用户互动，以及操作DOM。这决定了它只能是单线程，否则会带来很复杂的同步问题。比如，假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？
所以，为了避免复杂性，从一诞生，JavaScript就是单线程，这已经成了这门语言的核心特征，将来也不会改变。
为了利用多核CPU的计算能力，HTML5提出Web Worker标准，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM。所以，这个新标准并没有改变JavaScript单线程的本质。
so，既然需求使得js这门语言是单线程的，那也没办法是不是。
接下来我们来看看浏览器中js运行的方式。首先我们要明白一些概念。我们来看一张图
浏览器环境
我们看到，这里有以下几个概念。
1.堆 2.执行栈 3.执行队列
堆（ heap ）
什么是堆，通俗来讲堆就是存放地址的地方。比如说，堆中存放了一个一个的对象（Array object，Object object）。这些对象的指针指向的地址就是堆中存放的一个个的地址，当对象发生改变时，堆中地址的数据也会发生改变。这也就是为什么如果修改引用类型总会影响到其他指向这个地址的引用变量。
栈（ stack ）
什么是栈，再一次的通俗来讲。栈存放的就是我们的一些普通的变量（基本类型）。而且栈的执行顺序是先进后出。我们来模仿一下栈的执行顺序（类似js中的数组操作）。比如：
我们可以看到1最先入栈最后出栈。
队列
队列的执行方式是先进先出的。通俗来讲就像我们生活中的排队。比如说我们排队买票，先排队的人肯定先买到票然后从排的队中退出。队列就是这样一种效果。
了解过堆、栈和队列之后我们来看张图
浏览器中的eventloop
我们可以看到这里少了之前画的图中微任务和宏任务的队列的区分，其实是一样的。
我们来分析下。
上图中，主线程运行的时候，产生堆（heap）和栈（stack），栈中的代码调用各种外部API，它们在"任务队列"中加入各种事件（click，load，done）。只要栈中的代码执行完毕，主线程就会去读取"任务队列"，依次执行那些事件所对应的回调函数。
我们应该想一下，既然是依次执行执行队列的回调函数，那为什么之前的代码在浏览器和node中的代码执行结果是不一样的呢？这就要说一说我们之前提到的微任务和宏任务了。
微任务
Promise.then、（MutationObserve、MessageChannel）
宏任务
setTimeout setInterval (setImmediate)
浏览器中任务的执行方式大约是这样。执行栈先按执行队列的顺序执行，然后如果有微任务就执行微任务。如果没有微任务就执行宏任务。当宏任务执行队列中的一个方法执行完毕之后，执行栈会判断微任务队列中又没有需要执行的微任务，如果有则执行微任务。如果没有就执行当前执行栈中的任务。就像刚才那张图我们再看一下。
也就是我们的执行栈先执行两个setTimeout把他的回调方法放到宏任务队列中。遇见Promise.then方法就把他的回调放到微任务队列中。然后执行栈执行完第一个setTimeout的回调之后会判断微任务的执行队列中有没有需要执行的回调函数，当然这时我们的微任务队列中有刚才Promise.then的回调方法等待执行，然后我们的执行栈就会先执行微任务中的方法。当微任务执行完毕后才会回到宏任务队列中继续执行。
可能有一些绕。。我们再来捋一捋看张图
额。。个人理解
我们再来看下node中的事件执行机制。
node事件环
简单的来讲。就是node在执行过程中。执行栈会先执行完当前队列才会执行下一队列。比如我们之前的代码执行结果。
我们可以看到，执行栈会先执行完宏任务队列，也就是两个setTimeout中的回调函数执行完才会去执行我们的微任务队列。
所以我们看到node中的事件环和浏览器中的不同也就是这个样子。
也就是说node的执行栈会先按照顺序执行。然后把异步代码的回调放入到各自对应的执行队列中。当node在处理一个执行队列的时候不管怎样都会先执行当前队列，然后再去执行下一队列。
分享这篇文章，主要是可以让我们稍微了解一下在浏览器环境和node环境下代码的执行机制，也相当于我们代码的执行顺序。
大家看到这里也蛮不容易，谢谢大家的观看。祝好。就酱。
有兴趣了解Promise的可以戳一下这里：一步一步实现一个符合PromiseA+规范的Promise库（1）
再次感谢。
网友评论