为什么 Promise 比setTimeout() 快?

目录
文章目录隐藏
  1. 1.实验
  2. 2.事件循环
  3. 3.作业队列与任务队列
  4. 总结

1.实验

我们来做个实验。哪个执行得更快:立即解决的 Promise 还是立即setTimeout(也就是 0 毫秒的 setTimeout)?

Promise.resolve(1).then(function resolve() {
  console.log('Resolved!');
});

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

// 'Resolved!'
// 'Timed out!'

promise.resolve(1)是一个静态函数,它返回一个立即解析的promisesetTimeout(callback, 0)0 毫秒的延迟执行回调函数。

我们可以看到先打印'Resolved!',再打印Timeout completed!,立即解决的 promise 比立即setTimeout更快。

是因为Promise.resolve(true).then(...)setTimeout(..., 0)之前被调用了,所以 Promise 过程会更快吗? 公平的问题。

所以,我们稍微更改一下实验条件,然后先调用setTimeout(..., 0)

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

Promise.resolve(1).then(function resolve() {
  console.log('Resolved!');
});

// 'Resolved!'
// 'Timed out!'

setTimeout(..., 0)Promise.resolve(true).then(...)之前被调用。但,还是先打印Resolved!在打印'Timed out!'

这是为啥呢?

2.事件循环

与异步 JS 相关的问题可以通过研究事件循环来回答。我们回顾一下异步 JS 工作方式的主要组成部分。

异步 JS 工作方式

调用堆栈是一个 LIFO(后进先出)结构,它存储在代码执行期间创建的执行上下文。简单地说,调用堆栈执行这些函数。

Web api 是异步操作(fetch 请求、promise、计时器)及其回调等待完成的地方。

task queue (任务队列)是一个FIFO(先进先出)结构,它保存准备执行的异步操作的回调。例如,超时的setTimeout()的回调函数或准备执行的单击按钮事件处理程序都在任务队列中排队。

job queue (作业队列)是一个 FIFO(先入先出)结构,它保存准备执行的promise 的回调。例如,已完成的承诺的resolvereject回调被排在作业队列中。

最后,事件循环永久监听调用堆栈是否为空。如果调用堆栈为空,则事件循环查看作业队列或任务队列,并将准备执行的任何回调分派到调用堆栈中。

3.作业队列与任务队列

我们从事件循环的角度来看这个实验,我将对代码执行进行一步一步的分析。

(A)调用堆栈执行setTimeout(..., 0)并计划一个计时器, timeout()回调存储在 Web API 中:

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

Promise.resolve(1).then(function resolve() {
  console.log('Resolved!');
});

作业队列与任务队列

(B)调用堆栈执行 Promise.resolve(true).then(resolve)并安排一个 promise 解决方案。 resolved()回调存储在 Web API 中:

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

Promise.resolve(1).then(function resolve() {
  console.log('Resolved!');
});

resolved()回调存储在 Web API 中

(C)promise 立即被解析,同时计时器也立即执行。这样,定时器回调timeout()进入任务队列,promise回调resolve()进入作业队列

promise 回调 resolve()进入作业队列

(D)现在是有趣的部分:作业队列(微任务)优先级高于任务队列(宏任务)。 事件循环从作业队列中取出 promise 回调resolve()并将其放入调用堆栈中。 然后,调用堆栈执行 promise 回调resolve()

调用堆栈执行 promise 回调 resolve()

(E)最后,事件循环将计时器回调timeout()从任务队列中出队到调用堆栈中。 然后,调用堆栈执行计时器回调timeout()

调用堆栈执行计时器回调 timeout()

调用堆栈为空,已完成脚本的执行。

总结

为什么立即解决的 promise 比立即执行定时器setTimeout()处理得更快?

由于事件循环优先级的存在,因此与任务队列(存储超时的setTimeout()回调)相比,作业队列(用于存储已实现的Promise回调)的优先级更高。

「点点赞赏,手留余香」

0

给作者打赏,鼓励TA抓紧创作!

微信微信 支付宝支付宝

还没有人赞赏,快来当第一个赞赏的人吧!

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。
码云笔记 » 为什么 Promise 比setTimeout() 快?

发表回复