blog 全面认知 JavaScript 执行机制

全面认知 JavaScript 执行机制

Open nanyang24 opened this issue 6 years ago • 0 comments

是时候来一波总结了，之前的文章也有提到，虽然不全面，但如果你是 JS rookie，建议先看那篇再回来：深入理解 JS 的坑和细节的单线程和异步机制

本文重头戏在后半部分的 macrotask & microtask

那让我们开始吧！

首先，我们要有一个共同的认知：Javascript 是一门单线程语言，尽管 HTML5 标准中提出了 Web-Worker，但本质上 JS 是单线程这一核心仍未改变。

JavaScript 事件循环

任务可以分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。

同步任务指的是，在主线程上排队执行的任务，只有前一个任务执行完毕，才能执行后一个任务；
异步任务指的是，不进入主线程、而进入"任务队列"（task queue）的任务。

一旦当前"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行异步任务对应的回调函数。

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

主线程从"任务队列"中读取事件，这个过程是循环不断的，所以整个的这种运行机制又称为 Event Loop（事件循环）。

让我们看一小段简易的ajax请求代码：

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 的机制是这个样子

setTimeout(() => {
    task()
},3000)

sleep(10000000)

task()进入Event Table并注册，计时开始。
执行sleep函数，很久很久，但计时仍在继续。
3秒到了，计时事件 timeout 完成，task() 进入Event Queue，但 sleep 还是没结束，只好等着。
sleep终于执行完了，task()终于从Event Queue进入了主线程执行。

setTimeout这个函数，是经过指定时间后，把要执行的任务 (本例中为task()) 加入到 Event Queue 中，又因为是单线程任务要一个一个执行，如果前面的任务需要的时间太久，那么只能等着，导致真正的延迟时间远远大于3秒。

说完了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) 是类似 Node.js 版的 "setTimeout"，在事件循环的下一次循环中调用 callback 回调函数。

下面进入本文的重头戏：

除了之前提到的广义的同步任务和异步任务

任务其实分为两种：

Macro-tasks (宏任务): setTimeout & setInterval, MessageChannel, postMessage, setImmediate, I/O, UI rendering, requestAnimationFrame, 包括整体代码 script
Micro-tasks (微任务): process.nextTick, Promise.then, MutationObserver, Object.observe(废弃)

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

任务队列中，在每一次事件循环中，macro-task 只会提取一个来交给主线程执行，而 micro-task 则会一直提取，直到 micro-task 的队列为空为止。简单来说如果某个 micro-task 任务被推入到执行中，那么当主线程任务执行完成后，会循环调用该 微任务队列任务 中的下一个任务来执行，直到该任务队列到最后一个任务为止。而事件循环每次只会压入主栈中一个 macro-task，主线程执行完成该任务后又会检查 micro-task 队列并完成里面的所有任务后再执行下一个 macrotask 的任务。

ma-i-crotask--1-

这两个任务的区别就在于执行的时机，Macro-task 在一次主线程执行栈执行结束后浏览器进行渲染，然后才执行下一个 Macro-task。而 Micro-task 会影响IO回调，要是不断增加 Micro-task 的话，就一直无法渲染视图了，看上去就会卡顿。但 Macro-task 就没有这种危险。

如果这段话有些难理解，可以先看后面例子

实际上来说，Micro-task 并非每次都在主栈末尾才执行，如果一个函数执行完毕后，栈暂时空掉了，那么 Micro-task 也会执行

为啥要用microtask? 根据 HTML Standrad，在每个task(macrotask)运行完以后，UI都会重新渲染，那么在microtask中就完成数据更新，因此当前task结束就可以得到最新的UI了。反之：如果新建一个task(macrotask)来做数据更新的话，那么渲染会执行两次。

事件循环的顺序，决定 JS 代码的执行顺序。

进入整体代码(宏任务)后，开始第一次循环。执行整体代码，接着执行所有的微任务，至此，第一次循环结束。然后再找到宏任务的一个任务队列执行完毕，再执行其所有的微任务，第二次循环结束。听起来有点绕，下面用一段代码来说明：

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

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

console.log('console');

这段代码整体作为宏任务，进入主线程。
先遇到 setTimeout，那么将其回调函数注册后分发到宏任务Event Queue。(注册过程与上同，下文不再描述)
接下来遇到了 Promise，其中 new Promise 是立即执行的（不理解的快去看Promise教程），then函数分发到微任务Event Queue。
遇到 console.log()，立即执行。
至此，整体代码 script 作为第一个宏任务执行结束，看看有哪些微任务？我们发现了 then 在微任务 Event Queue里面，执行（如果此时微任务队里还有多个任务，会全部执行结束才进入下一次循环）。
Ok！第一轮事件循环结束了，我们开始第二轮循环，当然要从宏任务 Event Queue 开始。我们发现了宏任务 Event Queue 中 setTimeout 对应的回调函数输出'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与前端环境不完全相同，输出顺序可能会有误差

换种理解方式

本文叙述是以我的理解为原型：

主调用栈task
macro-task
micro-task

当然你可以理解为事件循环有一个或多个任务队列（任务队列是macrotask队列），每个事件循环都有micro-task。 也就是，macrotask queues 直接称为 task queues，而 microtask queues 单独的。

再次以这种理解方式回顾下事件循环如何执行一个任务的流程

文档： HTML Standard - event loop processing model

一个简易的事件循环过程模型如下

执行 macrotask 队列中最旧的任务，然后将其删除。
执行微任务队列中的所有可用任务，然后删除它们。
下一轮：运行 macrotask 队列中的下一个任务（跳转第2步）

要记住的东西：

当一个任务（在 macrotask 队列中）正在运行时，可能会注册新的事件。因此可能会创建新的任务。下面是两个新创建的任务：
- promiseA.then 的回调是一个任务
  - promiseA resolved/rejected：任务将在当前循环的事件循环中被推入微任务队列中。
  - promiseA pending：任务将在未来一轮的事件循环中被推入微任务队列（可能是下一轮）
- setTimeout(callback，n)的回调是一个任务，并且会被推入 macrotask 队列，甚至0秒也是这样;
microtask 队列中的任务都将在当前轮中运行，而 macrotask 队列中的任务必须等待下一轮事件循环。
我们都知道 “click”，“scroll”，“ajax”，“setTimeout”...的回调是任务，但是我们也应该记住 JS 代码作为一个整体脚本标记也是一个任务（macrotask）

以上理解在于将执行机制只分为 macrotask 和 microtask 任务队列 = macrotask队列 != microtask队列

阐述以上两种理解方式是为了让读者更好的理解事件循环的执行机制，因为网络上主要是这两种理解方式，其实在本质上两种本质是差不多的，只是看问题的角度有些不同，也就是 task 是否就等于 macrotask 。

最后

建议：

Basically, use microtasks when you need to do stuff asynchronously in a synchronous way (i.e. when you would say perform this (micro-)task in the most immediate future). Otherwise, stick to macrotasks.

基本上，当你需要以同步方式异步执行任务时（即在最近的将来执行这个（微）任务时），使用微任务。否则，坚持 macro-task

以上，就是 JavaScript 的执行机制了，当然在不同浏览器和Node会有些微差别。

Mar 04 '18 14:03 nanyang24

blog blog copied to clipboard

全面认知 JavaScript 执行机制

那让我们开始吧！

JavaScript 事件循环

宏任务 & 微任务

任务其实分为两种：

事件循环的顺序，决定 JS 代码的执行顺序。

换种理解方式

再次以这种理解方式回顾下事件循环如何执行一个任务的流程

一个简易的事件循环过程模型如下

要记住的东西：

阐述以上两种理解方式是为了让读者更好的理解事件循环的执行机制，因为网络上主要是这两种理解方式，其实在本质上两种本质是差不多的，只是看问题的角度有些不同，也就是 task 是否就等于 macrotask 。

最后

建议：

blog
blog copied to clipboard