总结：JavaScript异步、事件循环与消息队列、微任务与宏任务

本人正在努力学习前端，内容仅供参考。由于各种原因（不喜欢博客园的UI），大家可以移步我的github阅读体验更佳：传送门，喜欢就点个star咯，或者我的博客：https://blog.tangzhengwei.me

掘金：传送门，segmentfault：传送门

前言

Philip Roberts 在演讲 great talk at JSConf on the event loop 中说：要是用一句话来形容 JavaScript，我可能会这样：

“JavaScript 是单线程、异步、非阻塞、解释型脚本语言。”

  • 单线程 ?
  • 异步 ? ?
  • 非阻塞 ? ? ?

然后，这又牵扯到了事件循环、消息队列，还有微任务、宏任务这些。

作为一个初学者，对这些了解甚少。

这几天翻阅了不少资料，似乎了解到了一二，是时候总结一下了，它们困扰了我好一段时间，就像学高数那会儿自己去理解一个概念一样。

单线程与多线程

单线程语言：JavaScript 的设计就是为了处理浏览器网页的交互（DOM操作的处理、UI动画等），决定了它是一门单线程语言。

如果有多个线程，它们同时在操作 DOM，那网页将会一团糟。

JavaScript 是单线程的，那么处理任务是一件接着一件处理，从上往下顺序执行：

console.log(‘script start‘)
console.log(‘do something...‘)
console.log(‘script end‘)

// script start
// do something...
// script end

上面的代码会依次打印: "script start" >> "do something..." >> "script end"

那如果一个任务的处理耗时（或者是等待）很久的话，如：网络请求、定时器、等待鼠标点击等，后面的任务也就会被阻塞，也就是说会阻塞所有的用户交互（按钮、滚动条等），会带来极不友好的体验。

但是：

console.log(‘script start‘)

console.log(‘do something...‘)

setTimeout(() => {
  console.log(‘timer over‘)
}, 1000)

// 点击页面
console.log(‘click page‘)

console.log(‘script end‘)

// script start
// do something...
// click page
// script end
// timer over

"timer over" 在 "script end" 后再打印，也就是说计时器并没有阻塞后面的代码。那，发生了什么？

其实，JavaScript 单线程指的是浏览器中负责解释和执行 JavaScript 代码的只有一个线程，即为JS引擎线程，但是浏览器的渲染进程是提供多个线程的，如下：

  • JS引擎线程
  • 事件触发线程
  • 定时触发器线程
  • 异步http请求线程
  • GUI渲染线程

浏览器渲染进程参考这里

当遇到计时器、DOM事件监听或者是网络请求的任务时，JS引擎会将它们直接交给 webapi，也就是浏览器提供的相应线程（如定时器线程为setTimeout计时、异步http请求线程处理网络请求）去处理，而JS引擎线程继续后面的其他任务，这样便实现了 异步非阻塞。

定时器触发线程也只是为 setTimeout(..., 1000) 定时而已，时间一到，还会把它对应的回调函数(callback)交给 消息队列 去维护，JS引擎线程会在适当的时候去消息队列取出消息并执行。

JS引擎线程什么时候去处理呢？消息队列又是什么？

这里，JavaScript 通过 事件循环 event loop 的机制来解决这个问题。

这个放在后面再讨论吧！

同步与异步

上面说到了异步，JavaScript 中有同步代码与异步代码。

下面便是同步：

console.log(‘hello 0‘)

console.log(‘hello 1‘)

console.log(‘hello 2‘)

// hello 0
// hello 1
// hello 2

它们会依次执行，执行完了后便会返回结果（打印结果）。

setTimeout(() => {
  console.log(‘hello 0‘)
}, 1000)

console.log(‘hello 1‘)

// hello 1
// hello 0

上面的 setTimeout 函数便不会立刻返回结果，而是发起了一个异步，setTimeout 便是异步的发起函数或者是注册函数，() => {...} 便是异步的回调函数。

这里，JS引擎线程只会关心异步的发起函数是谁、回调函数是什么？并将异步交给 webapi 去处理，然后继续执行其他任务。

异步一般是以下：

  • 网络请求
  • 计时器
  • DOM时间监听
  • ...

事件循环与消息队列

回到事件循环 event loop

其实 事件循环 机制和 消息队列 的维护是由事件触发线程控制的。

事件触发线程 同样是浏览器渲染引擎提供的，它会维护一个 消息队列。

JS引擎线程遇到异步（DOM事件监听、网络请求、setTimeout计时器等...），会交给相应的线程单独去维护异步任务，等待某个时机（计时器结束、网络请求成功、用户点击DOM），然后由 事件触发线程 将异步对应的 回调函数 加入到消息队列中，消息队列中的回调函数等待被执行。

同时，JS引擎线程会维护一个 执行栈，同步代码会依次加入执行栈然后执行，结束会退出执行栈。

如果执行栈里的任务执行完成，即执行栈为空的时候（即JS引擎线程空闲），事件触发线程才会从消息队列取出一个任务（即异步的回调函数）放入执行栈中执行。

消息队列是类似队列的数据结构，遵循先入先出(FIFO)的规则。

执行完了后，执行栈再次为空，事件触发线程会重复上一步操作，再取出一个消息队列中的任务，这种机制就被称为事件循环（event loop）机制。

还是上面的代码：

console.log(‘script start‘)

setTimeout(() => {
  console.log(‘timer over‘)
}, 1000)

// 点击页面
console.log(‘click page‘)

console.log(‘script end‘)

// script start
// click page
// script end
// timer over

执行过程：

  1. 主代码块（script）依次加入执行栈，依次执行，主代码块为：

    • console.log(‘script start‘)
    • setTimeout()
    • console.log(‘click page‘)
    • console.log(‘script end‘)
  2. console.log() 为同步代码，JS引擎线程处理，打印 "script start"，出栈；
  3. 遇到异步函数 setTimeout，交给定时器触发线程（异步触发函数为：setTimeout，回调函数为：() => { ... }），JS引擎线程继续，出栈；
  4. console.log() 为同步代码，JS引擎线程处理，打印 "click page"，出栈；
  5. console.log() 为同步代码，JS引擎线程处理，打印 "script end"，出栈；
  6. 执行栈为空，也就是JS引擎线程空闲，这时从消息队列中取出（如果有的话）一条任务（callback）加入执行栈，并执行；
  7. 重复第6步。
  8. （此步的位置不确定）某个时刻（1000ms后），定时器触发线程通知事件触发线程，事件触发线程将回调函数 () => { ... } 加入消息队列队尾，等待JS引擎线程执行。

可以看出，setTimeout异步函数对应的回调函数( () => {} )会在执行栈为空，主代码块执行完了后才会执行。

零延时：

console.log(‘script start‘)

setTimeout(() => {
  console.log(‘timer 1 over‘)
}, 1000)

setTimeout(() => {
  console.log(‘timer 2 over‘)
}, 0)

console.log(‘script end‘)

// script start
// script end
// timer 2 over
// timer 1 over

这里会先打印 "timer 2 over"，然后打印 "timer 1 over"，尽管 timer 1 先被定时器触发线程处理，但是 timer 2 的callback会先加入消息队列。

上面，timer 2 的延时为 0ms，HTML5标准规定 setTimeout 第二个参数不得小于4（不同浏览器最小值会不一样），不足会自动增加，所以 "timer 2 over" 还是会在 "script end" 之后。

就算延时为 0ms，只是 timer 2 的回调函数会立即加入消息队列而已，回调的执行还是得等执行栈为空（JS引擎线程空闲）时执行。

其实 setTimeout 的第二个参数并不能代表回调执行的准确的延时事件，它只能表示回调执行的最小延时时间，因为回调函数进入消息队列后需要等待执行栈中的同步任务执行完成，执行栈为空时才会被执行。

宏任务与微任务

以上机制在ES5的情况下够用了，但是ES6会有一些问题。

Promise同样是用来处理异步的：

console.log(‘script start‘)

setTimeout(function() {
    console.log(‘timer over‘)
}, 0)

Promise.resolve().then(function() {
    console.log(‘promise1‘)
}).then(function() {
    console.log(‘promise2‘)
})

console.log(‘script end‘)

// script start
// script end
// promise1
// promise2
// timer over

WTF?? "promise 1" "promise 2" 在 "timer over" 之前打印了？

这里有一个新概念：macrotask（宏任务） 和 microtask（微任务）。

所有任务分为 macrotask 和 microtask:

  • macrotask：主代码块、setTimeout、setInterval等（可以看到，事件队列中的每一个事件都是一个 macrotask，现在称之为宏任务队列）
  • microtask：Promise、process.nextTick等

JS引擎线程首先执行主代码块。

每次执行栈执行的代码就是一个宏任务，包括任务队列(宏任务队列)中的，因为执行栈中的宏任务执行完会去取任务队列（宏任务队列）中的任务加入执行栈中，即同样是事件循环的机制。

在执行宏任务时遇到Promise等，会创建微任务（.then()里面的回调），并加入到微任务队列队尾。

microtask必然是在某个宏任务执行的时候创建的，而在下一个宏任务开始之前，浏览器会对页面重新渲染(task >> 渲染 >> 下一个task(从任务队列中取一个))。同时，在上一个宏任务执行完成后，渲染页面之前，会执行当前微任务队列中的所有微任务。

也就是说，在某一个macrotask执行完后，在重新渲染与开始下一个宏任务之前，就会将在它执行期间产生的所有microtask都执行完毕（在渲染前）。

这样就可以解释 "promise 1" "promise 2" 在 "timer over" 之前打印了。"promise 1" "promise 2" 做为微任务加入到微任务队列中，而 "timer over" 做为宏任务加入到宏任务队列中，它们同时在等待被执行，但是微任务队列中的所有微任务都会在开始下一个宏任务之前都被执行完。

在node环境下，process.nextTick的优先级高于Promise，也就是说：在宏任务结束后会先执行微任务队列中的nextTickQueue，然后才会执行微任务中的Promise。

执行机制：

  1. 执行一个宏任务（栈中没有就从事件队列中获取）
  2. 执行过程中如果遇到微任务，就将它添加到微任务的任务队列中
  3. 宏任务执行完毕后，立即执行当前微任务队列中的所有微任务（依次执行）
  4. 当前宏任务执行完毕，开始检查渲染，然后GUI线程接管渲染
  5. 渲染完毕后，JS引擎线程继续，开始下一个宏任务（从宏任务队列中获取）

总结

  • JavaScript 是单线程语言，决定于它的设计最初是用来处理浏览器网页的交互。浏览器负责解释和执行 JavaScript 的线程只有一个（所有说是单线程），即JS引擎线程，但是浏览器同样提供其他线程，如：事件触发线程、定时器触发线程等。
  • 异步一般是指：
    • 网络请求
    • 计时器
    • DOM事件监听
  • 事件循环机制：
    • JS引擎线程会维护一个执行栈，同步代码会依次加入到执行栈中依次执行并出栈。
    • JS引擎线程遇到异步函数，会将异步函数交给相应的Webapi，而继续执行后面的任务。
    • Webapi会在条件满足的时候，将异步对应的回调加入到消息队列中，等待执行。
    • 执行栈为空时，JS引擎线程会去取消息队列中的回调函数（如果有的话），并加入到执行栈中执行。
    • 完成后出栈，执行栈再次为空，重复上面的操作，这就是事件循环(event loop)机制。

原文链接

参考：

原文地址：https://www.cnblogs.com/ZavierTang/p/ZavierTang.html

时间： 2024-12-30 00:04:17

总结：JavaScript异步、事件循环与消息队列、微任务与宏任务的相关文章

node事件循环和消息队列简单分析

node的好处毋庸置疑,事件驱动,异步非阻塞I/O,以及处理高并发的能力深入人心,因此大家喜欢用node做一些小型后台服务或者作为中间层和其他服务配合完成一些大型应用场景. 什么是异步? 异步和同步应该是经常谈的一个话题了.同步的概念很简单,自上而下依次执行,必须等上边执行完下边才会执行.而异步可以先提交一个命令,中间可以去执行别的事务,而当执行完之后回过头来返回之前的任务. 举个栗子: 你很幸运,找了一个漂亮的女朋友,有一天你的女朋友发短信问你晚上看什么电影?但你并不知道看什么,马上打开电脑查

JavaScipt 中的事件循环机制，以及微任务 和宏任务的概念

说事件循环(event loop)之前先要搞清楚几个问题. 1. js为什么是单线程的? 试想一下,如果js不是单线程的,同时有两个方法作用dom,一个删除,一个修改,那么这时候浏览器该听谁的?这就是js被设计成单线程的原因. 2.js为什么需要异步? 如果js不是异步的话,由于js代码本身是自上而下执行的,那么如果上一行代码需要执行很久,下面的代码就会被阻塞,对用户来说,就是"卡死",这样的话,会造成很差的用户体验. 3.js是如何实现异步的? 既然js是单线程的,那么js是如何实现

对javascript EventLoop事件循环机制不一样的理解

前置知识点: 浏览器原理,浏览器内核5种线程及协作,JS引擎单线程设计推荐阅读: 从浏览器多进程到JS单线程,JS运行机制最全面的一次梳理 [FE]浏览器渲染引擎「内核」 js异步编程,Promise实现推荐阅读: Javascript异步编程的4种方法 前端面试必考题Promise的源码解析 堆.栈.队列.执行栈.任务.微任务.事件循环机制??推荐阅读: JavaScript异步编程-基础篇 彻底搞懂浏览器Event-loop 这一次,彻底弄懂 JavaScript 执行机制 一次弄懂Even

深入理解JavaScript的事件循环（Event Loop）

一.什么是事件循环 JS的代码执行是基于一种事件循环的机制,之所以称作事件循环,MDN给出的解释为 因为它经常被用于类似如下的方式来实现 while (queue.waitForMessage()) { queue.processNextMessage(); } 如果当前没有任何消息queue.waitForMessage 会等待同步消息到达 我们可以把它当成一种程序结构的模型,处理的方案.更详细的描述可以查看 这篇文章 而JS的运行环境主要有两个:浏览器.Node. 在两个环境下的Event

基于消息机制的异步架构之对消息队列的处理

/* *   handle.h */ #ifndef HANDLE_H_ #define HANDLE_H_ #include "msgqueue.h" typedef struct HANDLER{ int send_sock; char send_ip[128]; uint16 send_port; int ind; pthread_t  thread_id; //WORKER* father_thread; MSG_QUEUE* qmsg; }HANDLER; HANDLER*

进程间通信（二）——Posix消息队列

1.概述 消息队列可认为是消息链表.有足够写权限的线程可以往队列中放置消息,有足够读权限的进程可以从队列中取走消息.每个消息是一个记录,由发送着赋予一个优先级. 在像队列中写入消息时,不需要某个进程在该队列上等待消息到达.这与管道不同,管道必须现有读再有写. 消息队列具有随内核的持续性,与管道不同.进程结束后,消息队列中消息不会消失.当管道最后一次关闭,其中的数据将丢弃. 消息队列具有名字,可用于非亲缘关系的进程间. Posix消息队列读总是返回最高优先级的最早消息,而System V消息队列的

异步 JavaScript - 事件循环

简评:如果你对 JavaScript 异步的原理感兴趣,这里有一篇不错的介绍. JavaScript 同步代码是如果工作的 在介绍 JavaScript 异步执行之前先来了解一下, JavaScript 同步代码是如何执行的. 这里有两个概念需要了解: ** 执行上下文(Excution Context)** 执行上下文是一个抽象的概念,用于表示 JavaScript 的运行环境,任何代码都会有一个执行上下文. 全局代码运行在全局执行上下文,函数里的代码运行在函数执行上下文,每一个函数都有自己的

深入理解JavaScript事件循环机制

前言 众所周知,JavaScript 是一门单线程语言,虽然在 html5 中提出了 Web-Worker ,但这并未改变 JavaScript 是单线程这一核心.可看HTML规范中的这段话: To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this section. Ther

使用事件和消息队列实现分布式事务（转+补充）

虽然本文并非笔者原创,但是我们在非强依赖的事务中原理上也是采用这种方式处理的,不过因为没有仔细去总结,最近在整理和总结时看到了,故转载并做部分根据我们实际情况的完善和补充. 不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一