事件循环(Call Stack、Task Queue、Event Loop)

事件循环(Call Stack、Task Queue、Event Loop)

EventLoop(事件循环)认识

JavaScript 事件循环(Event Loop)是JavaScript运行时环境(比如浏览器或Node.js)的核心机制,允许 JavaScript 在执行异步代码时不阻塞主线程。这个机制使得 JavaScript 在执行长时间运行的任务(比如 I/O 操作、计时器等)时仍然能响应用户输入和执行其他任务

🍎作用

Event Loop是我们编写高效、非阻塞的 JavaScript 代码的核心。

Event Loop用于协调同步代码、异步代码以及各种任务的执行。

Event Loop使JavaScript这个单线程语言能够实现非阻塞的异步操作

确保程序不会因为阻塞操作(如长时间运行的计算)而导致用户界面或其他任务的冻结

🍎核心概念

事件循环的核心概念是 执行栈(Call Stack)、任务队列(Task Queue) 和 事件循环(Event Loop) 本身

执行栈 (Call Stack)----后进先出(LIFO模式-- Last In, First Out)

任务队列(Task Queue)---先进先出(FIFO模式 First In, First Out)

🍎解释

我们可以把Event Loop想象成一个永不停歇的循环,它不断地检查两个地方

一个是主线程的执行栈(Call Stack)

另一个是任务队列(Task Queue)

当执行栈清空时,Event Loop就会从任务队列中取出任务,放到执行栈中执行

🍎事件循环的工作原理

通过几个步骤来实现:

  • 任务队列(Task Queue) 事件循环不断检查任务队列,查看是否有任务需要执行。 任务可能是用户输入事件、I/O操作完成的通知、定时器的到期等。
  • 调用栈(Call Stack) 调用栈用于管理当前正在执行的代码。如果调用栈为空且任务队列中有任务, 事件循环将从任务队列中取出任务,并将其推送到调用栈中执行。
  • 非阻塞I/O操作: 在事件循环机制中,长时间运行的I/O操作(例如网络请求、文件读写)不会阻塞主线程, 而是将这些任务交给其他线程处理。 当I/O操作完成时,相关的回调函数会被放入任务队列中,等待事件循环去执行。

🍎JavaScript中的事件循环

在JavaScript中,事件循环在浏览器中或Node.js环境中都得到了广泛应用

JavaScript是单线程的,通过事件循环,可以处理大量的异步任务,而不会阻塞用户界面或其他任务

🍎异步编程与事件循环

异步编程通过回调、Promiseasync/await实现。事件循环确保这些异步操作按照正确的顺序执行,即使它们在代码中是非顺序的

微任务队列(Microtasks)

Promise的回调函数、MutationObserver的回调函数等会被放到微任务队列中。微任务的优先级高于宏任务,事件循环会在执行下一个宏任务前,先执行微任务队列中的所有任务

🍎优化异步代码

事件循环是实现非阻塞I/O操作、提高系统响应速度、优化用户体验的关键技术。在单线程环境中,它能有效地管理大量并发操作,写Event loop的时候我们需要注意到:

避免长时间运行的同步代码

长时间运行的同步代码会阻塞主线程,导致页面卡顿。如果遇到耗时操作,考虑将其拆分为多个小任务,或者使用Web Workers在后台线程中执行。

合理使用Promiseasync/await

Promiseasync/await是处理异步操作的强大工具,能够让代码更清晰、易维护。但滥用await可能会导致性能问题,例如在循环中频繁使用await

理解任务优先级

清楚宏任务和微任务的执行顺序,可以避免不必要的bug

进程(Process)和线程(Thread)

🍎进程

是计算机中运行的一个程序实例,代表着一个程序在内存中的执行。

每个进程都拥有独立的地址空间、代码、数据、文件描述符等资源,进程之间是相互独立的。

进程是操作系统管理的基本单位。

🍎线程

是进程中的一个执行单元,是程序执行的最小单位。

线程是进程内的一个执行流,指的是执行一段指令所需的时间。

一个进程可以包含一个或多个线程,这些线程共享进程的资源(如内存空间、文件描述符等)但每个线程有自己独立的执行栈。

线程之间的切换比进程之间的切换要轻便得多,因此,线程更适合用来进行多任务处理。

举个例子

比如我们打开手机上的一个app,就打开了一个进程。看到页面就开始了一个渲染线程,发消息开始了一个消息线程。这些线程共享微信进程的内存空间,各自执行不同的任务。

浏览器进程(Process)和线程(Thread)

浏览器也是多进程的应用程序,打开一个浏览器Tab页面时,就意味着开启了一个新的浏览器进程。

进程是独立的,所以即使其中一个Tab崩溃了,也不会影响到其他Tab的正常运行。

浏览器进程内部,有许多线程在协同工作,最终将网页内容展示出来。

我们理解Event Loop最密切相关的有以下几种线程

🍎HTTP请求线程(网络线程)

负责处理网络请求,下载前端(HTML、CSS、JavaScript)文件,或发送Ajax请求获取数据。

🍎JS引擎线程

负责解析和执行JavaScript代码。JavaScript是单线程的,这意味着在同一时间,JS引擎线程只能做一件事。

🍎渲染线程(GUI渲染线程)

负责解析HTML和CSS,构建DOM树和渲染树,并最终将页面绘制到屏幕上。当页面需要重绘或回流时,也是它来完成。

需要注意:JS引擎线程和渲染线程是互斥的。

意味着当JS引擎线程在执行JavaScript代码时,渲染线程会被挂起,无法进行页面的渲染。反之亦然。这就是为什么长时间运行的JavaScript代码会阻塞页面渲染,导致页面"卡死"的原因。而其他线程之间,比如HTTP请求线程和JS引擎线程,则可以并行工作,互不影响。

JavaScript的单线程特性与异步

🍎JavaScript单线程的原因

JavaScript被设计成单线程的,主要是为了避免DOM操作的复杂性。

如果JavaScript是多线程的,当多个线程同时操作同一个DOM元素时,就会出现竞态条件(Race Condition),导致不可预测的结果。

例如,一个线程要删除某个DOM元素,另一个线程要修改它,那么到底应该以哪个线程的操作为准呢?为了避免这种复杂性,JavaScript从诞生之初就被设计为单线程。

这意味着,JavaScript引擎在执行代码时,默认只开启一个线程工作。这个线程就是我们前面提到的JS引擎线程。负责从头到尾地执行JavaScript代码,一次只处理一个任务。

🍎单线程异步机制如何处理耗时操作-挂起

既然JavaScript是单线程的,那如何处理那些耗时很长的操作呢?网络请求(Ajax)、定时器(setTimeout、setInterval)或者文件读写?

如果这些操作都同步执行,在它们完成之前,JS引擎线程就会一直被阻塞,导致页面长时间无响应,用户体验极差。

为解决这个问题,JavaScript引入了异步机制。当JS引擎线程遇到异步代码时,它不会等待异步操作完成,而是会将其"挂起",交给其他线程(比如浏览器提供的Web APIs)去处理,然后JS引擎线程继续执行后续的同步代码。当异步操作完成后,它会将一个"任务"放入任务队列(Task Queue)中,等待JS引擎线程空闲时再来处理。

🍎同步代码与异步代码的区别

同步代码

按照代码顺序,一行一行执行。只有前一行代码执行完毕才能执行下一行。如果某一行代码耗时很长,那么后续代码都会被阻塞。

plain 复制代码
console.log('Start');
alert('这是一个同步操作,会阻塞页面'); // 阻塞
console.log('End');

打印 'Start'

弹出警告框

只有点击确定后,才会打印 'End'。

在警告框弹出期间,页面是无法进行任何操作的。

异步代码

不会立即执行,而是会被"挂起",等待某个条件满足(比如定时器时间到了,网络请求回来了)后,再将对应的回调函数放入任务队列,等待JS引擎线程空闲时执行。异步代码不会阻塞主线程的执行。

plain 复制代码
console.log('Start');
setTimeout(() => {
  console.log('Async operation finished');
}, 0);
console.log('End');

代码的执行顺序是

先打印 'Start',然后setTimeout被挂起,JS引擎线程继续执行,打印 'End'。最后,当JS引擎线程空闲时(即使setTimeout设置的时间是0毫秒),setTimeout的回调函数才会被执行,打印 'Async operation finished'。这就是异步的魅力,它让JavaScript在单线程的环境下也能处理复杂的、耗时的任务,而不会阻塞用户界面。

🍎任务队列的概念

任务队列是一个先进先出(FIFO)的队列,用于存放异步操作完成后需要执行的回调函数。当异步操作(比如setTimeout的计时结束,或者Ajax请求成功返回数据)满足了执行条件时,它们对应的回调函数并不会立即执行,而是会被放入这个任务队列中排队。JS引擎线程会在执行完所有同步代码后,才从任务队列中取出任务来执行。这个不断从任务队列中取出任务并执行的过程,就是Event Loop的核心所在。

宏任务(Macro-tasks)与微任务(Micro-tasks)

在JavaScript的异步世界里,任务被分成了两种类型:宏任务(Macro-tasks)和微任务(Micro-tasks)。这两种任务在Event Loop中有着不同的优先级和执行时机。

宏任务(Macro-tasks)包括:

  • setTimeout
  • setInterval
  • I/O操作(例如网络请求 ajax、文件读写)
  • UI渲染
  • setImmediate (Node.js环境特有)

微任务(Micro-tasks)包括:

  • Promise.then()Promise.catch()Promise.finally()
  • process.nextTick (Node.js环境特有)
  • MutationObserver (用于监听DOM变化)

Event Loop的执行顺序详解

宏任务和微任务是理解理解JavaScript异步编程的关键:

🍎执行宏任务,执行完毕=> 清空微任务=> 渲染页面(如果需要)=> 继续下一个宏任务

  1. 执行同步代码: 当JavaScript代码开始执行时,会首先执行所有的同步代码。这些同步代码可以被看作是当前宏任务的一部分。在执行过程中,如果遇到异步任务(无论是宏任务还是微任务),就会将其对应的回调函数放入相应的任务队列中。
  2. 清空微任务队列: 当所有同步代码执行完毕后,Event Loop并不会立即去执行宏任务队列中的任务。它会优先检查并清空微任务队列。意味着,所有在当前宏任务执行期间产生的微任务,都会在下一个宏任务开始之前被执行完毕。
  3. 页面渲染(可选): 在微任务队列清空之后,如果浏览器判断有必要进行页面渲染(比如DOM结构发生了变化,或者需要更新UI),它就会进行一次页面渲染。这一步是可选的,浏览器会根据实际情况决定是否进行渲染。
  4. 执行下一个宏任务: 页面渲染完成后,Event Loop会从宏任务队列中取出一个任务来执行。这个任务执行完毕后,又会重复步骤2,检查并清空微任务队列,然后再次进行页面渲染(如果需要),接着再从宏任务队列中取出下一个任务......如此循环往复,直到所有任务执行完毕。

async/await

🍎await关键字在Event Loop中的表现

async/await是ES2017引入的异步编程语法糖,它让异步代码看起来像同步代码一样,极大地提高了代码的可读性和可维护性。

await的底层实现依然是基于Promise和Event Loop的。

🍎await的本质:将后续代码推入微任务队列

当你使用await关键字时,它会暂停async函数的执行,直到await后面的Promise对象状态变为resolvedrejected。而await的精妙之处在于,它会将await后面的代码(即async函数中await表达式之后的代码)推入微任务队列。

这意味着,当await等待的Promise解决后,async函数中被暂停的代码会作为微任务被添加到微任务队列中,等待当前宏任务执行完毕,并且所有已有的微任务执行完毕后,才会轮到它执行。

🍎浏览器对await执行时间的优化

🌂早期版本async/await

在早期的async/await实现中,await 是基于传统的事件循环机制实现的。

await 后面的异步操作(如 Promise)被"暂停"并放入 微任务队列,而 await 本身会让代码的执行变得"同步化"

即浏览器会等待 await 后的异步任务执行完毕后,再继续执行下面的代码。导致在一些情况下,await 可能会带来比必要的更多的延时。

以前的await执行原理(已过时)

在旧的实现中,await会将await后面的代码(即async函数中await表达式之后的代码)作为一个微任务放入微任务队列。

await表达式本身,如果它等待的是一个Promise,那么这个Promisethen方法也会产生一个微任务。这可能导致一些复杂的执行顺序问题。

🌂导致的问题:

不必要的延时

如果 await 的异步操作已经很快执行完毕,浏览器仍然会等待当前执行周期的其他同步任务完成,导致一些不必要的延迟。

回调队列的拥塞

当多个异步任务并行执行时,await 后的代码会推迟到事件循环的微任务队列中,可能会造成回调的堆积和延迟。

🌂新版本

微任务队列优化

现在 await 在很多情况下会直接在当前事件循环内执行,而不需要推迟到下一个事件循环。这样,当异步操作快速完成时,await 可以更快地继续执行后续代码。

优先级调整

现代的JavaScript引擎会更智能地调度微任务,优先执行即将完成的异步任务,减少不必要的延迟。

现在的await执行顺序

现在,await的执行机制可以这样理解:当await一个Promise时,它会"阻塞"async函数的执行,直到Promise解决。一旦Promise解决,await会立即将async函数中await表达式后面的代码作为微任务添加到微任务队列中。而await表达式本身,可以被看作是立即执行的,它只是等待一个值。

结合代码示例深入分析await的执行流程:

让我们通过一个具体的例子来理解await的执行流程。假设我们有以下代码:

plain 复制代码
// async.js
async function async1() {
  console.log("async1 start");
  await async2();
  console.log("async1 end");
}

async function async2() {
  console.log("async2");
}

console.log("script start");

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

async1();

new Promise(function (resolve) {
  console.log("promise1");
  resolve();
}).then(function () {
  console.log("promise2");
});

console.log("script end");

请你预测一下这段代码的输出顺序

我们来一步步分析:

  1. console.log("script start"): 首先执行同步代码,输出 script start
  2. setTimeout: 遇到setTimeout,将其回调函数放入宏任务队列。
  3. async1(): 调用async1函数。
  • console.log("async1 start"):async1函数内部,首先输出 async1 start
  • await async2(): 遇到awaitasync2函数被调用,输出 async2
  • await会暂停async1的执行,并将async1await后面的代码(即console.log("async1 end"))放入微任务队列。
  1. new Promise(...): 继续执行同步代码,遇到Promise
  • console.log("promise1")Promise构造函数是同步执行的,所以立即输出 promise1
  • resolve()Promise状态变为resolved
  • .then(...)then方法的回调函数被放入微任务队列。
  1. console.log("script end"): 继续执行同步代码,输出 script end

至此,所有的同步代码执行完毕。此时,微任务队列中有两个任务:

  1. async1await后面的代码 (console.log(async1 end"))
  2. Promise.then的回调 (console.log(promise2"))

根据Event Loop的执行顺序,接下来会清空微任务队列:

  1. 执行微任务队列: 先执行async1await后面的代码,输出 async1 end
  2. 执行微任务队列: 再执行Promise.then的回调,输出 promise2

微任务队列清空后,检查宏任务队列:

  1. 执行宏任务队列: 执行setTimeout的回调,输出 setTimeout

最终的输出顺序是:

plain 复制代码
script start
async1 start
async2
promise1
script end
async1 end
promise2
setTimeout

这个例子完美地展示了async/await在Event Loop中的执行机制,以及微任务的优先级高于宏任务的特性。

常见误区

理解了Event Loop的原理,我们再来看一些实际场景和常见的误区

🍎经典题

Event Loop是前端常客,尤其是关于输出顺序的题目。除了上面async/await的例子,我们再来看一个经典的题目:

plain 复制代码
// 1.js
console.log("script start");

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

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

console.log("script end");

做一下这段代码的输出顺序以后我们分析一下

同步代码=> 微任务队列 => 下一个宏任务

  1. console.log("script start"): 首先执行同步代码,输出 script start
  2. setTimeout: 遇到setTimeout,将其回调函数放入宏任务队列。
  3. Promise.resolve().then(...)Promise.resolve()会立即返回一个已解决的Promise。它的第一个.then回调函数被放入微任务队列。
  4. console.log("script end"): 继续执行同步代码,输出 script end

至此,所有同步代码执行完毕。此时微任务队列中有:promise1的回调。

  1. 执行微任务队列: 执行promise1的回调,输出 promise1。注意,promise1的回调执行完毕后,它返回的Promise会立即resolve,因此其后面的.then回调(promise2)会立即被放入微任务队列。
  2. 继续执行微任务队列: 执行promise2的回调,输出 promise2

微任务队列清空。检查宏任务队列:

  1. 执行宏任务队列: 执行setTimeout的回调,输出 setTimeout

最终的输出顺序是:

plain 复制代码
script start
script end
promise1
promise2
setTimeout

注意微任务的优先级。即使setTimeout的延迟时间设置为0,它也必须等待当前宏任务中的所有微任务执行完毕后才能执行。

🍎错误理解与纠正

  1. 误区:setTimeout(fn, 0)会立即执行。纠正:setTimeout(fn, 0)表示将fn放入宏任务队列,等待主线程空闲且所有微任务执行完毕后,在下一个宏任务阶段执行。它并不能保证立即执行,只是表示"尽快"执行。

  2. 误区:async/await是同步的。纠正:async/await只是语法糖,它让异步代码看起来像同步代码,但其本质仍然是基于Promise的异步操作,并且await后面的代码会被推入微任务队列,遵循Event Loop的规则。

  3. 误区:只要是异步代码,就一定会比同步代码后执行。纠正: 这句话不完全正确。异步代码的回调函数确实会在同步代码执行完毕后才执行,但微任务的优先级高于宏任务。所以,在同步代码执行完毕后,会先执行所有微任务,再执行宏任务。

相关推荐
Jolyne_11 分钟前
树节点key不唯一的勾选、展开状态的处理思路
前端·算法·react.js
饺子不放糖12 分钟前
workspace:你真的会用吗?
前端
饺子不放糖15 分钟前
dependencies vs devDependencies:别再傻傻分不清,你的 package.json 可能早就"胖"了!
前端
岁忧19 分钟前
(LeetCode 面试经典 150 题) 104. 二叉树的最大深度 (深度优先搜索dfs)
java·c++·leetcode·面试·go·深度优先
Kevin@wust21 分钟前
axios的封装
前端·vue
teeeeeeemo23 分钟前
Ajax、Axios、Fetch核心区别
开发语言·前端·javascript·笔记·ajax
Juchecar24 分钟前
TypeScript对 null/undefined/==/===/!=/!== 等概念的支持,以及建议用法
javascript
柏成29 分钟前
基于 pnpm + monorepo 的 Qiankun微前端解决方案(内置模块联邦)
前端·javascript·面试
唐诗43 分钟前
VMware Mac m系列安装 Windws 11,保姆级教程
前端·后端·github
ZXT1 小时前
Chrome Devtool
前端