生成器函数如何影响事件循环？

在文章实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《生成器函数如何影响JavaScript事件循环？》，聊聊，希望可以帮助到正在努力赚钱的你。

生成器函数通过协作式暂停和恢复执行，间接避免阻塞主线程。1.生成器函数使用function*声明，调用时返回迭代器对象，通过next()方法控制执行流程；2.每次调用next()，生成器执行到yield表达式暂停，并将控制权交还调用者；3.在yield暂停时，事件循环有机会处理其他微任务或宏任务；4.生成器本身是同步的，但通过手动分解任务并在关键点yield，可显式释放主线程；5.async/await基于生成器和Promise实现，自动化恢复执行，而生成器需手动调用next()；6.两者均提供同步化异步代码的能力，但async/await更专注于异步操作，语法更简洁，错误处理更直观。

JavaScript的生成器函数本身并不会改变事件循环的底层机制，它们更像是在单线程环境中提供了一种精妙的“暂停”和“恢复”代码执行的能力。这种能力允许我们更细粒度地控制函数的执行流程，从而在特定时机将控制权交还给事件循环，处理其他任务，而不是粗暴地阻塞它。

解决方案

生成器函数，以 function* 声明，提供了一种全新的方式来处理迭代或管理异步操作。当你调用一个生成器函数时，它并不会立即执行其内部代码，而是返回一个迭代器对象。这个迭代器有一个 next() 方法。每次调用 next()，生成器都会执行其内部的代码，直到遇到一个 yield 表达式。当遇到 yield 时，生成器会“暂停”执行，将 yield 后面的值返回给调用者，并有效地将控制权交还给调用 next() 的那段代码。

这里有个关键点：这种“暂停”是协作式的。它不会神奇地将任务推送到事件循环的队列中。它所做的是允许当前的执行上下文（即调用 next() 的地方）完成其工作，然后事件循环就可以处理其他挂起的微任务或宏任务了。当 next() 方法再次被调用时，生成器会从它上次暂停的地方继续执行，直到遇到下一个 yield 或 return 语句。

所以，生成器函数对事件循环的“影响”是间接的。通过允许一个函数在执行过程中暂停和恢复，它防止了长时间运行的同步代码完全霸占调用栈。你可以设计你的生成器，在关键的计算点或数据处理阶段进行 yield，从而给事件循环一个喘息的机会，去处理UI更新、网络请求响应或其他回调。这其实是一种更精细的控制流管理。

生成器函数如何避免阻塞主线程？

说实话，生成器函数本身是同步执行的。yield 关键字确实会暂停生成器的执行，但这种暂停和随后的恢复（通过 next() 调用）仍然是当前调用栈中的同步操作。那么，“避免阻塞主线程”这个说法，其实更多地取决于你如何使用它们。

如果你有一个计算量很大的任务，常规的做法是把它一次性跑完，这很容易导致主线程长时间被占用，用户界面卡顿。但通过生成器，你可以把这个大任务分解成许多小块，每个小块之间用 yield 分隔开。在每次 yield 和下一次 next() 调用之间，JavaScript 引擎就有机会去检查事件循环，看看有没有其他待处理的任务。

举个例子，假设你要处理一个巨大的数组。与其在一个 for 循环里一次性处理几百万个元素，你可以每处理完几千个元素就 yield 一次。然后在调用代码中，你可以把 next() 的调用包裹在 setTimeout(..., 0) 或 requestAnimationFrame 里。这样，你就在每一次处理小块数据后，显式地将控制权交还给事件循环，让它有机会去处理像用户点击、网络响应或者UI渲染这样的任务。这本质上是一种手动实现的协作式多任务处理。核心在于，你可以控制生成器何时 yield，何时将控制权返回给调用者，从而给事件循环一个执行的机会。

yield 关键字在事件循环中的实际作用是什么？

yield 关键字本身并不会直接操作事件循环的队列（比如把一个任务推进去）。它的核心作用是暂停生成器函数的执行，并将一个值返回给它的调用者。当 yield 被遇到时，生成器内部的状态会被保存起来。接着，调用 generator.next() 的那段代码会继续执行。

事件循环的机会就出现在这里：因为生成器已经暂停了，当前的调用栈可以“回退”，然后 JavaScript 运行时就能检查微任务队列（例如 Promise 的解决/拒绝回调），接着是宏任务队列（例如 setTimeout 的回调、DOM 事件），看看是否有其他挂起的操作需要处理。

所以，yield 并不是向事件循环“添加”任务，而是它创建了一个“断点”，一个事件循环可以介入并执行其任务的机会。它避免了生成器函数内部长时间的同步执行完全阻塞事件循环。这是一种合作式的移交控制权，而不是一个自动的调度机制。

生成器函数与 async/await 在异步编程中的异同？

我个人觉得，理解生成器函数和 async/await 的关系，就像理解底层机制和上层语法糖的关系。它们在处理异步方面有异曲同工之妙，但设计目标和使用方式还是有区别的。

相似之处：

• 同步化异步代码： 它们都提供了一种编写异步代码的方式，让代码看起来像同步一样，从而更容易理解和维护那些依赖于顺序执行的异步操作。
• 暂停与恢复： async/await 在本质上就是基于生成器和 Promise 实现的。两者都允许函数执行在某个点暂停，并在稍后恢复。

不同之处：

• 目的与侧重：
  • 生成器函数是更通用的迭代器，可以用来创建自定义的可迭代对象，管理复杂的状态机，或者实现前面提到的协作式多任务。
  • async/await 则是专门为异步操作设计的，主要用于处理 Promise。
• 自动化程度：
  • async/await 自动化了恢复执行的“管道”工作。当你 await 一个 Promise 时，函数会自动暂停，直到 Promise 解决或拒绝，然后自动恢复执行。
  • 而原生的生成器，你需要手动调用 next() 来恢复执行。这意味着，如果你用生成器处理异步操作，通常还需要一个“运行器”函数（比如一个基于 Promise 的 co-routine 库）来管理 next() 的调用时机。
• 错误处理：
  • async/await 使用标准的 try...catch 块来捕获 Promise 的拒绝，这非常直观和自然。
  • 生成器虽然也能用 try...catch，但处理由生成器 yield 出来的异步操作的错误，往往需要更多手动管理，比如通过 generator.throw() 方法来注入错误。
• 语法糖： async/await 可以说是 Promise 和生成器的语法糖，它提供了一种更简洁、更易读的语法来表达常见的异步模式。生成器则是一个更底层的原语。

对事件循环的影响：

两者都能够实现非阻塞的异步操作。async/await 隐式地利用了微任务队列（Promise 的解决）来调度 async 函数的恢复执行。而生成器，通过 yield，则提供了一个手动的钩子，允许你在关键点主动让出控制权，让事件循环有机会运行。可以说，async/await 是 JavaScript 运行时为你自动管理了生成器的 next() 调用，并将其与事件循环的微任务队列紧密结合起来，使得异步流程更加顺滑。

以上就是《生成器函数如何影响事件循环？》的详细内容，更多关于的资料请关注golang学习网公众号！