读完这篇文章 —— 真正了解JS运行机制

前面的话

最近读了一篇文章，帮助我更好的理解了JS运行机制，js是一门单线程语言，Event Loop(事件循环)是它的运行机制，接下来分享的内容将以最小的成本了解JS运行机制。

JS事件循环

我们都知道，js的任务分为同步任务与异步任务。当我们打开网站时，网页渲染的过程就是一大推同步任务，比如页面骨架和页面元素的渲染。而像加载图片音乐等占用资源耗时就的任务，就是异步任务。我们用一个图来说明。

解释一下导图：

• 同步和异步任务分别进入不同的执行“场所”，同步的进入主线程，异步的进入Event Table并注册回调函数。
• 当指定的事情完成时，Event Table会将这个函数移入Event Queue。
• 主线程内的任务执行完毕为空时，会去Event Queue 读取对应的函数，进入主线程执行
• 上述过程会不断重复，也就是常说的Event Loop

那么怎么知道主线程执行栈为空？js引擎存在monitoring process进程，会持续不断的检查主线程执行栈是否为空，一旦为空，就会去Event Queue那里检查是否有等待被调用的函数。

看一个例子：

 let data = [];
    $.ajax({
        url: www.javaScript.com,
        data: data,
        success: () => {
            console.log('发送成功')
        }
    });
    console.log('代码执行结束');

• ajax进入event table,注册回调函数success。
• 执行console.log(‘代码执行结束’)。
• ajax事件完成，回调函数success进入event queue
• 主线程从event queue读取回调函数success并执行。

setTimeout

通过上面的代码，js的执行顺序有了初步了解，接下来研究平时用的较多的setTimeout。

我们经常这么实现延时3秒执行：

   setTimeout(() => {
            console.log('延时3秒')
        },3000);

但用的多了，就会发现有时明明写的是延时3秒，实际延时却是5,6秒才执行函数，这是怎么回事呢？

先看一个例子：

 setTimeout(() => {
            task();
        },3000)
  console.log('执行console');

setTimeout是典型的的异步，应该先执行console.log(‘执行console’)这个同步任务，所以执行结果是：

// 执行console
// task()

修改一下上面的代码：

    setTimeout(() => {
        task();
    },3000);
    sleep(10000000);

sleep()是一个同步任务，它执行的很慢。那么在控制台上执行task()需要的时间远远超过3秒，这是为什么呢？

我们重新来理解一个setTimeout的定义。首先先说一下代码时怎么执行的：

• task()进入Event Table并注册函数，计时开始。
• 执行sleep()函数，很慢（大于3秒），计时仍在继续。
• 3秒到了，计时事件setTimeout()完成，task进入Event Queue，但是sleep()函数还未执行完，只好等着
• 等到sleep()函数执行完之后，task()从Event Queue 进入主线程执行

上述的流程走完之后，我们知道setTimeout这个函数，是经过指定时间后，把要执行的任务(task())加入到Event Queue中，又因为js是单线程任务要一个一个执行，如果前面的任务需要执行的时间太久，那么只能等着，导致真正的时间大于3秒。

我们经常还会遇到setTimeout(fn, 0)这样的代码，0秒后执行又是什么意思呢？是不是立即执行呢？

答案是不会立即执行，setTimeout(fn, 0)的含义是，指定某个任务在主线程最早可得的空闲时间执行，意思就是不用等多少秒，只要主线程执行的同步任务全部执行完成，栈为空时就立即执行。看一个例子：

    // 代码1
    console.log('先执行这里');
    setTimeout(() => {
        console.log('执行了')
    }, 0);

    // 代码2
    console.log('先执行这里');
    setTimeout(() => {
        console.log('执行了')
    }, 3000);


    代码1输出的结果：
    // 先执行这里
    // 执行啦

    代码2输出的结果：
    // 先执行这里
    // ... 3s later
    // 执行啦

关于setTimeout要补充的是，即便主线程为空，0ms实际上也是达不到的。根据HTML的标准，最低也是4ms。

setInterval()

说完了setTimeout，当然也要聊一聊它的孪生兄弟setInterval。他俩差不多，只不过后者是循环的执行。对于执行循环来说，setInterval每隔指定的事件将注册的函数置入Event Queue,如果前面的任务耗时太久，那么同样需要等待。

[注意]

对于setInterval(fn, ms) 来说，我们知道不是每隔ms秒回执行一次fn,而是每隔ms秒会有fn进入Event Queue。一旦setInterval的回调函数fn执行时间超过了延迟时间ms，那么久完全看不出来有时间间隔了。

Promise与process.nextTick(callback)

传统的定时器我们已经研究过了,接下来研Promise、process.nextTick(callback)。

Promise的定义小柒前一篇文章详细解释了process.nextTick(callbcak)类似node.js版的“setTimeout”,在事件循环的下一次循环中调用callback 回调函数。

下面进入正题，除了广义的同步任务和异步任务，我们对任务有更精细的定义：

• macro-task(宏任务)：包括整体代码 script，setTimeout，setInterval、messageChannel
• micro-task(微任务)：Promise(指的是then(),而不是new Promise())，promise.nextTick、mutationObserve

不同类型的任务会进入对应的Event Queue，比如setTimeout与setInterval会进入相同的Event Queue。

事件循环的顺序，决定js代码的执行循序。进入整体代码(宏任务)后，开始第一次循环。接着执行所有的微任务，然后再次从宏任务开始，找到其中的一个任务执行完毕，再执行所有的微任务。用一段代码来说明：

    setTimeout(function() {
    console.log('setTimeout');
   });

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

    console.log('console');

    // promise
    // console
    // then 
    // setTimeout

• 这段代码作为宏任务，进入主线程
• 先遇到setTimeout，那么将其回调函数注册后发到宏任务Event Queue
• 接下里遇到new Promise 立即执行，then函数分发到微任务Event Queue
• 遇到console.log()，立即执行
• 整体代码作为第一个宏任务执行结束，看看有哪些微任务，发现有then()在微任务，执行
• 第一轮事件循环结束，开始第二轮事件循环，从宏任务Event Queue开始。发现宏任务Event Queue中有setTimeout对应的回调函数，立即执行
• 结束

事件循环，宏任务，微任务的关系如图所示：

我们来分析一段较复杂的代码，看看你是否真的掌握了js的执行机制：

console.log('1');

setTimeout(function() {
    console.log('2');
    process.nextTick(function() {
        console.log('3');
    });
    new Promise(function(resolve) {
        console.log('4');
        resolve();
    }).then(function() {
        console.log('5')
    });
});

process.nextTick(function() {
    console.log('6');
});

new Promise(function(resolve) {
    console.log('7');
    resolve();
}).then(function() {
    console.log('8');
})

setTimeout(function() {
    console.log('9');
    process.nextTick(function() {
        console.log('10');
    });
    new Promise(function(resolve) {
        console.log('11');
        resolve();
    }).then(function() {
        console.log('12');
    })
})

第一轮事件循环流程分析如下：

• 整体script作为第一个宏任务进入主线程，遇到console.log，输出1。
• 遇到setTimeout，其回调函数被分发到宏任务Event Queue中。我们暂且记为setTimeout1。
• 遇到process.nextTick()，其回调函数被分发到微任务Event Queue中。我们记为process1。
• 遇到Promise，new Promise直接执行，输出7。then被分发到微任务Event Queue中。我们记为then1。
• 又遇到了setTimeout，其回调函数被分发到宏任务Event Queue中，我们记为setTimeout2。

宏任务Event Queue	微任务Event Queue
setTimeout1	process1
setTimeout2	then1

上表是第一轮事件循环宏任务结束时各Event Queue的情况，此时已经输出了1和7。

我们发现了process1和then1两个微任务。

• 执行process1,输出6。
• 执行then1，输出8。

好了，第一轮事件循环正式结束，这一轮的结果是输出1，7，6，8。那么第二轮时间循环从setTimeout1宏任务开始：

• 首先输出2。接下来遇到了process.nextTick()，同样将其分发到微任务Event Queue中，记为process2。
• new Promise立即执行输出4，then也分发到微任务Event Queue中，记为then2。

宏任务Event Queue	微任务Event Queue
setTimeout2	process2
	then2

• 第二轮事件循环宏任务结束，我们发现有process2和then2两个微任务可以执行。
  输出3。
  输出5。
• 第二轮事件循环结束，第二轮输出2，4，3，5。
• 第三轮事件循环开始，此时只剩setTimeout2了，执行。
• 直接输出9。
• 将process.nextTick()分发到微任务Event Queue中。记为process3。
• 直接执行new Promise，输出11。
• 将then分发到微任务Event Queue中，记为then3。

宏任务Event Queue	微任务Event Queue
	process3
	then3

• 第三轮事件循环宏任务执行结束，执行两个微任务process3和then3。
• 输出10。
• 输出12。
• 第三轮事件循环结束，第三轮输出9，11，10，12。

整段代码，共进行了三次事件循环，完整的输出为1，7，6，8，2，4，3，5，9，11，10，12。(请注意，node环境下的事件监听依赖libuv与前端环境不完全相同，输出顺序可能会有误差)

参考：
作者：ssssyoki
链接：https://juejin.im/post/59e85eebf265da430d571f89
来源：掘金