js异步从入门到放弃（三）- 异步任务队列(task queues)

时间 2019-11-08

标签异步入门放弃任务队列 task queues 栏目 JavaScript 繁體版

原文原文链接

前言

本文是对于异步系列第一篇里提到的evenloop模型中，所提到的任务队列(task queues)的展开分析html

正文

说明：如下代码均使用chrome浏览器运行关于浏览器表现的差别在最后作补充。web

引子-奇怪的执行顺序

先看一个典型的例子:chrome

console.log('script start')
// 第一个异步任务
setTimeout(()=>{
    console.log('setTimeout')
},0)

// 第二个异步任务
Promise.resolve().then(()=>{
    console.log('promise1')
}).then(()=>{ 
  console.log('promise2');
})
console.log('script end')
// 实际输出结果： 
// script start
// script end
// promise1
// promise2
// setTimeout

根据以前说过的evenloop模型，首先输出script start和script end没有什么问题;
可是接下来却发现：
先执行了Promise指定的callback而不是setTimeout的callback。-- Why？api

两种任务队列(`microtask queue`&`macrotask queue`)

在以前讨论evenloop模型时，粗略提到了任务队列有2种类型:microtask queue和macrotask queue，他们的区别在于:promise

macrotask的执行：是在evenloop的每次循环过程，取出macrotask queue中可执行的第一个（注意不必定是第一个，由于咱们说过例如setTimeout能够指定任务被执行的最少延迟时间，当前macrotask queue的首位保存的任务可能尚未到执行时间，因此queue只是表明callback插入的顺序，不表明执行时也要按照这个顺序）。
microtask的执行：在evenloop的每次循环过程以后,若是当前的执行栈(call stack)为空，那么执行microtask queue中全部可执行的任务

（某些文献内容中直接把macrotask称为task,或者某些中文文章中把它们翻译成"微任务"和"宏任务"，含义都是类似的：macrotask或者task表明相对单独占据evenloop过程一次循环的任务，而microtask有可能在一次循环中执行多个）浏览器

如今回头来解析前面的例子：app

第一次执行主函数，输出script start
遇到setTimeout，将对应的callback插入macrotask queue
遇到promise，将对应的callback插入microtask queue
输出script end，主函数运行结束，执行栈清空，此时开始检查microtask queue，发现里面有可运行的任务，所以按顺序输出promise1和promise2
microtask queue执行完，开始新一轮循环，从macrotask queue取出setTimeout任务并执行，输出setTimeout
结束，呈现上面的输出结果。

常见异步操做对应的回调函数任务类型以下：dom

macrotask: setTimeout, setInterval, setImmediate, requestAnimationFrame, I/O, UI rendering
microtask: process.nextTick, Promises, Object.observe, MutationObserver

大概能够这样区分：和html交互密切相关的异步操做，通常是macrotasks；由emcascript的相关接口返回的异步操做，通常是microtaskswebapp

如何判断执行顺序

接下来看一个更复杂的例子，帮助理解不一样异步任务的执行顺序异步

<style>
    .outer {
        padding: 30px;
        background-color: aqua;

    }

    .inner {
        height: 100px;
        background-color: brown;
    }
</style>

<body>
    <div class="outer">outer
         <div class="inner">inner</div> 
    </div>
</body>
<script>
    var outer = document.querySelector('.outer');
    var inner = document.querySelector('.inner');

    // Let's listen for attribute changes on the
    // outer element
    new MutationObserver(function () {
        console.log('mutate');
    }).observe(outer, {
        attributes: true
    });

    // Here's a click listener…
    function onClick() {
        console.log('click');

        setTimeout(function () {
            console.log('timeout');
        }, 0);

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

        outer.setAttribute('data-random', Math.random());
    }

    // …which we'll attach to both elements
    inner.addEventListener('click', onClick);
    outer.addEventListener('click', onClick);

运行以上代码，能够在浏览器看到两个嵌套的div（如图）:

点击inner部分，打开chrome的调试器，能够看到console打出的结果是:

click
promise
mutate
click
promise
mutate
timeout
timeout

接下来分析运行过程 (建议打开chrome单步调试，进行观察分析)：

点击inner,触发对应的onClick事件，此时inner对应的onClick函数进入执行栈；
运行console.log('click'),输出(1)click；
运行setTimeout,macrotask queue添加对应的console函数
运行Promise，此时microtask queue添加对应的console函数
运行outer.setAttribute,触发MutationObserver,microtask queue添加对应的console函数（前面注明了MutationObserver建立的回调任务类型是microtask）
当前函数执行完毕，因为执行栈清空，此时开始调度microtask queue，所以依次输出(2)promise和(3)mutate，此时当前执行栈call stack和microtask queue均为空，可是macrotask queue里依然存储着两个东西--inner的Click触发的任务，以及先前setTimeout的回调函数。
inner的onclick函数虽然执行完毕，可是因为事件冒泡，紧接着要触发outer的onClick的执行函数，所以setTimeout的回调暂时还没法执行。
outer的onClick函数执行过程，重复前面的2-5步骤，所以输出(4)click (5)promise (6)mutate
此时执行栈call stack和microtask queue均为空，macrotask queue存储着两个setTimeout的回调函数。，根据evenloop模型，开始分别执行这两个task，因而输出了两个(7)和(8)timeout
结束。

再次建议在调试器查看上面的步骤，尤为要注意观察call stack、microtask queue macrotask queue的变化，会更加直观

在充分理解上面例子的基础上，咱们把点击inner部分的这个操做，改为直接在js代码的末尾加上innner.click()，请问结果是否一致呢？

先说最终结果:

click
click
promise
mutate
promise
timeout
timeout

与前一次的结果彻底不一样！
接下来再次进入调试分析:

因为是直接执行inner.click(),此次进入inner绑定的onclick函数时，与前面是有所不一样的:

经过chrome调试器能够看到，此时的call stack有两层--除了onClick函数以外，还有一层匿名函数，这层函数其实就是最外层的script，至关于window.onload绑定的处理函数。

这是很关键的一点！！！就是这一个区别，致使了整个执行结果的差别。
由于前面的例子的执行顺序是：

页面加载后先运行了整个匿名函数
函数出栈
点击时触发inner的onclcik
此时onClick对应的函数进栈。

两次执行到onclick时的callstck区别如图：

第一次，经过点击inner触发click：

第二次，经过代码直接触发click

接下来分析本次的输出顺序：

重复前面例子中，步骤2-5，输出一个(1)click
inner的onClick函数执行完毕，可是此次执行栈并未清空，由于当前匿名函数还在执行栈里，所以没法开始调度microtask queue！！！（前面说过，microtask queue的调度必须在当前执行栈为空的状况下），所以，这时候会先进入冒泡事件触发的onClick
相似的，输出(2)clcik以后，promise的回调函数进入microtask queue
运行outer.setAttribute,触发MutationObserver,可是此时microtask queue没法再次添加对应的回调函数了，由于已经有一个存在的监听函数在pengding
两个onclick执行完毕，执行栈清空，接下来开始调度microtask queue,输出(3)promise (4)mutate (5)promise
此时当前执行栈call stack和microtask queue均为空，macrotask queue存储着两个setTimeout的回调函数。根据evenloop模型，开始分别执行这两个task，因而输出了两个(6)和(7)timeout
结束

这两个例子的对比，着重说明了一点:
--microtask queue存储的任务，必需要在当前函数执行栈为空时才会开始调度。
完整内容可参见html标准中的8.1.4部分

结论

macrotask会按顺序执行，而且有可能被中途插入浏览器render，例如上面的冒泡事件
microtask的执行有两个条件：
1. 在每一个macrotask结束以后
2. 当前call stack为空

ps:浏览器差别

上述代码在chrome的浏览器下测试结果，可能和在某些版本的firefox和ie浏览器下不一致，在某些浏览器中可能会把promise的回调函数当作mascrotask，可是:

广泛的共识把 Promise当作是 miscrotask，而且有比较充分的理由：若是把promose当作是task(即mascrotask)将会致使一些性能问题--由于task的调度是能够被其余task相关的任务如 Render打断，还会由于与其余任务源的交互致使不肯定性。

参考文献

Tasks, microtasks, queues and schedules
HTML Living Standard

若是以为写得很差/有错误/表述不明确，都欢迎指出
若是有帮助，欢迎点赞和收藏，转载请征得赞成后著明出处。若是有问题也欢迎私信交流，主页有邮箱地址
若是以为做者很辛苦，也欢迎打赏~