async/await在事件循环中通过微任务队列实现非阻塞异步流程管理。它基于promise，将异步代码以同步方式书写，提升可读性；当执行await时，若为promise则挂起async函数并交还控制权给事件循环，待promise解决后将后续代码作为微任务入队；与promise.then()同属微任务机制，但语法更直观，支持try…catch错误处理；async/await本身不阻塞主线程，但同步长任务仍会阻塞，可通过web workers或任务分解避免。
JavaScript中async/await在事件循环中扮演的角色，简单来说，就是提供了一种优雅且非阻塞的方式来管理异步操作的执行顺序。它并没有改变事件循环的底层机制，而是巧妙地利用了微任务队列，让异步代码看起来像同步代码一样线性执行，同时又确保了主线程的响应性。
解决方案
async/await本质上是Promise的语法糖，它的核心作用在于将异步操作的流程扁平化，使得原本基于回调函数或Promise链的复杂异步逻辑，能以更接近同步代码的直观方式书写。
当你在一个async函数内部使用await关键字时，如果await后面的表达式是一个Promise，那么当前async函数的执行会被“暂停”，注意，这里是暂停当前函数，而不是阻塞整个JavaScript主线程。此时，控制权会立即交还给事件循环，允许其他待处理的任务（宏任务或微任务）得以执行。一旦被await的Promise解决（resolved）或拒绝（rejected），async函数剩余的部分（await语句之后的代码）就会被封装成一个微任务（microtask），并被推入到事件循环的微任务队列中。
立即学习“Java免费学习笔记（深入）”；
微任务队列的优先级高于宏任务队列（如setTimeout, setInterval的回调），这意味着一旦主线程空闲下来，它会优先清空微任务队列中的所有任务，然后才会去处理宏任务队列中的下一个任务。正是这种机制，使得async/await能够在不阻塞主线程的前提下，实现异步代码的有序执行，确保了用户界面的流畅性和应用的响应速度。它避免了回调地狱，让异步错误处理也变得更像同步代码中的try...catch。
当一个await表达式被遇到时，究竟发生了什么？
嗯，这是一个挺有意思的问题，因为它触及了async/await工作原理的精髓。当你写下await somePromise()时，JavaScript引擎并没有直接停在那里等你。实际上，它做了一些很巧妙的事情。
首先，await会尝试“解包”它后面的值。如果这个值不是一个Promise，它会立即将其转换为一个已解决的Promise，并继续执行。但如果它是一个Promise（这才是我们通常期待的情况），async函数会在这里“挂起”。这里的“挂起”并不是说主线程被冻结了，而是当前async函数的执行上下文被保存起来，并且该函数会立即返回一个Promise（这个Promise就是async函数本身最终会返回的Promise）。
接着，JavaScript引擎会将控制权交还给事件循环。这意味着，在somePromise()还在后台执行（比如在网络请求中）的时候，事件循环可以自由地去处理其他排队的任务：可能是渲染更新，可能是用户交互事件，也可能是其他setTimeout的回调。
当somePromise()最终解决（fulfilled）或拒绝（rejected）时，一个关键的步骤发生了：async函数剩余的部分（也就是await语句之后的所有代码）会被包装成一个微任务，并被放置到微任务队列中。请记住，微任务队列的优先级非常高。这意味着，只要主线程一空闲下来（比如当前执行的宏任务完成），它会立即检查微任务队列，并执行其中的所有微任务，包括我们刚刚提到的async函数剩余的部分。
所以，你看，await并没有“等待”在原地，而是优雅地“让步”，把舞台留给其他任务，直到它所依赖的异步操作完成，然后才通过微任务机制，重新获得执行的机会。
async function fetchData() { console.log('1. 开始获取数据...'); const response = await new Promise(resolve => setTimeout(() => { console.log('2. 模拟数据获取完成'); resolve('一些数据'); }, 1000)); // 1秒后Promise解决 console.log('3. 数据已处理:', response); return response;}console.log('0. 调用fetchData');fetchData().then(data => { console.log('4. fetchData Promise解决:', data);});console.log('5. 同步代码继续执行');// 预期输出顺序：// 0. 调用fetchData// 1. 开始获取数据...// 5. 同步代码继续执行// (1秒后)// 2. 模拟数据获取完成// 3. 数据已处理: 一些数据// 4. fetchData Promise解决: 一些数据
在这个例子中，当await new Promise(...)被遇到时，fetchData函数暂停，5. 同步代码继续执行会立即打印。1秒后，Promise解决，fetchData的剩余部分（打印3.）被作为微任务加入队列，然后被执行。
async/await和Promise.then()在事件循环中有什么异同？
从事件循环的角度看，async/await和Promise.then()在核心机制上其实是同宗同源的，因为async/await就是基于Promise实现的语法糖。它们都依赖于微任务队列来调度异步操作的后续执行。
相同点：
微任务队列: 无论是Promise.then()的回调函数，还是async函数中await之后剩余的代码，它们在被调度执行时，都会被放入微任务队列。这意味着它们都享有比宏任务（如setTimeout、setInterval、I/O操作的回调）更高的执行优先级。非阻塞: 它们都不会阻塞JavaScript的主线程。当异步操作进行时，主线程可以继续处理其他任务，保持应用的响应性。异步性质: 它们都是处理异步操作的工具，用于解决那些需要等待外部资源（如网络请求、文件读写、定时器）完成才能继续执行的代码逻辑。
不同点（主要是语法和流程控制的便利性）：
语法结构: Promise.then()使用链式调用，通过回调函数来处理异步结果。这在深层嵌套时容易导致“回调地狱”。而async/await则允许你用更接近同步代码的线性方式书写异步逻辑，大大提升了代码的可读性和可维护性。错误处理: Promise.then().catch()是处理Promise错误的标准方式。async/await则可以直接使用同步的try...catch语句来捕获await的Promise拒绝（rejected）的错误，这让错误处理变得更加直观和熟悉。流程控制: 在处理多个异步操作时，Promise.all()、Promise.race()等方法通常与Promise.then()结合使用。而在async/await中，你可以更自然地使用for...of循环来迭代异步操作，或者使用Promise.all()与await结合，实现并行等待。隐式Promise: async函数总是返回一个Promise，即使你没有显式地return new Promise()。它的返回值会被自动封装成一个已解决的Promise。而Promise.then()的回调函数，如果返回一个非Promise值，会被包装成一个已解决的Promise；如果返回一个Promise，则链会继续。
简单来说，async/await是JavaScript在语言层面提供的一种更高级的抽象，它让开发者能够以更直观、更少“精神负担”的方式来驾驭异步编程，但其底层仍然是Promise和事件循环微任务机制在支撑。
async/await是否会阻塞主线程，以及如何避免？
一个常见的误解是，await关键字会阻塞主线程。这其实是不对的，async/await的设计初衷恰恰是为了避免阻塞主线程。正如前面所说，当await一个Promise时，async函数会暂停，并将控制权交还给事件循环，让主线程能够继续处理其他任务。
然而，尽管async/await本身是非阻塞的，但在async函数内部，如果你执行了长时间运行的同步计算，那确实会阻塞主线程。比如，一个计算量巨大的循环，或者一个复杂的数学运算，它们本身是同步的，会一直占用CPU直到完成。即使它们在一个async函数内部，只要没有遇到await，它们就会持续执行，从而阻塞事件循环，导致页面卡顿，无法响应用户输入或动画。
如何避免阻塞主线程：
将耗时计算移至Web Workers： 这是处理CPU密集型任务最推荐的方式。Web Workers在后台线程中运行，不会阻塞主线程。当计算完成后，它们可以通过postMessage将结果发送回主线程。
// worker.jsonmessage = function(e) { const result = /* 执行耗时计算 */; postMessage(result);};// main.jsasync function performHeavyCalculation() { const worker = new Worker('worker.js'); return new Promise((resolve, reject) => { worker.onmessage = (e) => resolve(e.data); worker.onerror = (e) => reject(e.message); worker.postMessage('start'); });}async function processData() { console.log('开始处理...'); const result = await performHeavyCalculation(); // 这里等待Web Worker的结果 console.log('处理完成:', result);}processData();
分解大任务，利用await或setTimeout进行“让步”： 如果一个任务无法完全放入Web Worker（比如它需要直接操作DOM），你可以尝试将其分解成更小的部分，并在每个部分之间插入await Promise.resolve()或await new Promise(resolve => setTimeout(resolve, 0))。这本质上是利用微任务或宏任务的调度机制，在每个小任务之间将控制权短暂交还给事件循环，让浏览器有机会处理其他事件或更新UI。
async function processLargeArray(arr) { for (let i = 0; i setTimeout(resolve, 0)); // 宏任务，让出更久 } } console.log('数组处理完毕');}// 实际应用中，这种方法适用于轻度阻塞，重度阻塞仍推荐Web Workers
避免在async函数中执行不必要的同步长循环： 审视你的代码，看看是否有可以优化或重构的同步循环。有时候，算法优化本身就能解决问题。
记住，async/await是管理异步流程的利器，它让代码更清晰。但它不是解决所有性能问题的银弹，尤其对于那些纯粹的CPU密集型计算，你仍然需要考虑Web Workers这样的并发方案。
以上就是JavaScript中async/await是如何影响事件循环的的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1511510.html
微信扫一扫 
支付宝扫一扫 
