一、 JavaScript为什么需要异步 ?

为什么需要异步

如果JavaScript中不存在异步, 只能自上而下执行, 如果上一行解析时间很长, 那么下面的代码就会被阻塞.对于用户而言, 阻塞就意味着 "卡死", 这样就导致了很差的用户体验.所以, JavaScript中存在异步执行

那么异步又是如何实现的呢?

任务队列 :1. 所有同步任务都在主线程上执行, 形成一个执行栈(stack)。2.主线程之外, 还存在一个任务队列Event Loop, 异步任务在event table中注册函数, 当满足触发条件(即DOM，AJAX，setTimeout，setImmediate有返回结果了) 后, 被推入任务队列(Event Loop)。3. 一旦执行栈(stack) 中所有同步任务都执行完了, 系统就会读取任务队列(Event Loop), 看看里面有哪些事件.那些对应的异步任务, 于是结束等待状态, 进入执行栈, 开始执行 。4.主线程不断重复上面的第三步。

例子如下图：

图

运行的结果是：1，3，2 代码分析：

1.console.log(1)是同步任务，放入主线程里

2.setTimeout是异步任务，被放入event table，0秒之后被推入任务队列(Event Loop)里

3.console.log(3)是同步任务，放到主线程里.

当1，3在控制台被打印后，主线程去Event Loop(事件队列)里查看是否有可执行的函数，执行setTimeout里的函数，这就是Event Loop

二、Java Script是单线程的

单程线

为什么呢 ? 首先JavaScript语言的一大特点就是单线程, 通俗点说就是, 同一个时间只能做一件事.那么会又有新的问题, JavaScript为什么不能有多个线程呢 ?

JavaScript最初被设计用在浏览器中, 那么设想下, 浏览器中的JavaScript是多线程的.例如 : 假定JavaScript同时有两个线程, 一个线程在某个DOM节点上添加内容, 另外一个线程删除了这个节点, 这时浏览器应该以哪个线程为准呢 ?

后来, HTML5提出Web Worker标准, 允许JavaScript脚本创建多个线程, 但是子线程完全受主线程控制, 且不得操作DOM, 所以, 这个新标准并没有改变JavaScript单线程本质

三、Event Loop是什么 ?

主线程从任务队列(Event Loop) 中读取事件, 这个过程是循环不断的, 所以整个的这种运行机制又称为Event Loop(事件循环).

上图中, 主线程运行的时候, 产生堆(heap) 和栈(stack), 栈中的代码调用各种外部API， 它们在” 任务队列(Event Loop)” 中加入各种事件（ click， load， done）。 只要栈中的代码执行完毕， 主线程就会去读取” 任务队列(Event Loop)”， 依次执行那些事件所对应的回调函数。

例子2：

试按照，上文我们刚学到的js执行机制去分析：

1.setTimeout 是异步任务，被放到event table

2.new Promise是同步任务，被放到主线程里，直接执行打印console.log('马上执行for循环啦');

3..then里的函数是异步任务，被放到event table

4.console.log('代码执行结束');是同步代码，被放到主线程里，直接执行

所以根据分析的结果是：马上执行for循环啦---代码执行结束---定时器开始啦---执行then函数啦

自己运行了下代码后，结果居然不是这样的，而是：马上执行for循环啦---代码执行结束---执行then函数啦---定时器开始啦

事实上，按照异步和同步的方式来划分，并不准确，而准确的划分方式是：macro-task(宏任务)：script(整体代码), setTimeout, setInterval, setImmediate, I/O, UI rendering。micro-task(微任务)：process.nextTick, Promise, Object.observe(已废弃), MutationObserver(html5新特性)

图示

按照这种分类方式，js的执行机制是：

1.执行一个宏任务，过程中如果遇到微任务，就将其放到微任务的"事件队列"里

2.当前宏任务执行完成后，会查看微任务的"事件队列"，并将里面全部的微任务依次执行完

3.重复以上2步骤，结合图1和图2就是更为准确的js执行机制了

那么，去分析例2:

1.首先执行script下的宏任务，遇到setTimeout,将其放到宏任务的“队列”里

2.遇到 new Promise直接执行，打印"马上执行for循环啦"

3.遇到then方法，是微任务，将其放到微任务的“队列”里。

4.遇到console.log('代码执行结束');是同步任务，直接打印"代码执行结束"

5.本轮宏任务执行完毕，查看本轮的微任务，发现有一个then方法里的函数，打印"执行then函数啦"

6.到此,本轮的event loop 全部完成。

7.下一轮的循环里，先执行一个宏任务，发现宏任务的“队列”里有一个setTimeout里的函数,执行打印"定时器开始啦" 所以最后的执行顺序是： 马上执行for循环啦---代码执行结束---执行then函数啦---定时器开始啦

四、定时器setTimeout()和setInterval()

定时器指定某些代码在多少时间之后执行这叫做”定时器”（timer）功能，也就是定时执行的代码。 例子3：

setTimeout(function(){ console.log('执行了') },3000)

我们一般会说：3秒后，会执行setTimeout里的那个函数，但是这种说法并不严谨，准确的解释是：3秒后，setTimeout里的函数会被推入事件队列(Event Loop)，而事件队列(Event Loop)里的任务，只有在主线程空闲时才会执行，所以条件只有同时满足(ps:3秒后并且主线程空闲)时，才会3秒后执行函数

如果主线程执行内容很多，执行时间超过3秒，比如主线程里执行栈执行了10秒，那么这个函数只能10秒后执行了

五、Node.js的Event Loop

Node.js也是单线程的Event Loop，但是它的运行机制不同于浏览器环境。

图示

如图所示，Node.js的运行机制如下：

1.V8引擎解析JavaScript脚本。

2.解析后的代码，调用Node API。

3.libuv库负责Node API的执行。它将不同的任务分配给不同的线程，形成一个Event

Loop（事件循环），以异步的方式将任务的执行结果返回给V8引擎。

4.V8引擎再将结果返回给用户。

除了setTimeout和setInterval这两个方法，Node.js还提供了另外两个与”任务队列”有关的方法：process.nextTick和setImmediate。它们可以帮助我们加深对”任务队列”的理解。nextTick setImmediate 区别和联系nextTick :把回调函数放在当前执行栈的底部,而多个process.nextTick语句总是在当前”执行栈”一次执行完setImmediate :把回调函数放在事件队列(event loop)的尾部,而多个setImmediate可能则需要多次loop才能执行完

例子4：

上面代码中，由于process.nextTick方法指定的回调函数，总是在当前”执行栈”的尾部触发，所以不仅回调函数A比setTimeout指定的回调函数timeout先执行，而且函数B也比timeout先执行。这说明，如果有多个process.nextTick语句（不管它们是否嵌套），将全部在当前”执行栈”执行。所以结果是：1，2，'TIMEOUT FIRED'

现在，再来看看setImmediate例子5：

上面代码中，setImmediate与setTimeout(fn,0)各自添加了一个回调函数A和timeout，都是在下一次事件队列(Event Loop)触发。那么，哪个回调函数先执行呢？答案是不确定。运行结果可能是1,TIMEOUT FIRED,2，也可能是TIMEOUT FIRED,1,2。

令人困惑的是，Node.js文档中称，setImmediate指定的回调函数，总是排在setTimeout前面。实际上，这种情况只发生在递归调用的时候。

例子6：

上面代码中，setImmediate和setTimeout被封装在一个setImmediate里面，它的运行结果总是1，TIMEOUT FIRED，2，这时函数A一定在timeout前面触发。至于2排在TIMEOUT FIRED的后面（即函数B在timeout后面触发），是因为setImmediate总是将事件注册到下一轮事件队列(Event Loop)，所以函数A和timeout是在同一轮Loop执行，而函数B在下一轮Loop执行

另外，由于process.nextTick指定的回调函数是在本次”事件循环”触发，而setImmediate指定的是在下次”事件循环”触发，所以很显然，前者总是比后者发生得早，而且执行效率也高（因为不用检查”任务队列”）。

作者：酱油88