asyncio 的 Event Loop：定义、运行机制与工程实践

1. 为什么需要 Event Loop

在 asyncio 中，event loop 是整个异步运行时的调度核心。它本身并不“完成业务逻辑”，而是负责在适当的时机推进协程、触发回调、处理 I/O 事件、安排定时器，并把不同来源的异步工作组织成一套可预测的执行序列。

如果把协程理解为“可暂停、可恢复的函数”，那么 event loop 就是负责“何时暂停、何时恢复、恢复哪一个”的调度器。离开 event loop，协程对象只是一个尚未执行的可等待对象；只有被事件循环驱动之后，异步代码才会真正向前推进。

从职责上看，event loop 至少承担以下几类任务：

• 维护待执行回调队列
• 维护定时任务队列
• 监听 I/O 就绪事件
• 推进 Task 和 Future 的状态迁移
• 处理取消、关闭与异常传播
• 在适当时机回收异步生成器、线程池等资源

因此，理解 asyncio，实质上就是理解 event loop 如何驱动 coroutine、Task、Future 与 I/O 事件协同工作。

2. Event Loop 的规范定义

从抽象层面说，event loop 是一个反复迭代的调度循环。每一轮迭代通常都会经历如下阶段：

1. 取出已到期的定时回调。
2. 处理已经就绪的 I/O 事件。
3. 执行 ready queue 中的回调。
4. 推进被 Future 唤醒的 Task。
5. 计算下一次 poll 的等待时间，进入下一轮。

这个过程并不是由业务代码手工逐步驱动，而是由循环本身持续执行，直到满足停止条件。其核心思想可以概括为：

• 当某个协程执行到 await 时，它会让出控制权。
• event loop 转而去执行其他就绪任务。
• 当等待的 I/O、定时器或 Future 完成后，event loop 再恢复先前挂起的协程。

这就是协作式并发的根本机制。它不同于抢占式线程调度：协程是否让出执行权，取决于程序是否显式进入等待点。

3. asyncio.run() 与“谁来拥有事件循环”

在常规 Python 脚本中，最推荐的入口是 asyncio.run(coro)。它代表一条明确的工程约定：

• 创建一个新的事件循环
• 将给定协程包装并运行到完成
• 在结束前关闭异步生成器
• 清理默认执行器
• 关闭事件循环

因此，应用层代码通常不应优先从 loop.run_until_complete(...) 开始，而应优先从 asyncio.run(...) 开始。前者属于偏底层控制接口，适合框架、运行时集成或需要精细掌控生命周期的场景；后者才是一般业务程序的首选入口。

不过在 Jupyter Notebook、某些 Web 框架、GUI 框架或测试运行器中，事件循环往往已经存在。此时如果再直接调用 asyncio.run(...)，通常会抛出“已有运行中的事件循环”异常。因此在 Notebook 中，更自然的方式往往是直接使用顶层 await。

下面两种写法分别代表两类典型场景：

import asyncio
async def main():
    await asyncio.sleep(1)
    print("done")
# 脚本程序的推荐入口
asyncio.run(main())

# Notebook / 已有运行时环境中的常见写法
await main()

4. 事件循环中的几个核心对象

理解 event loop 时，必须严格区分以下概念：

coroutine object

调用 async def 函数不会立即执行函数体，而是得到一个 coroutine object。它只是待执行的协程实例。

Task

Task 是 event loop 对 coroutine 的调度包装。只有当协程被包装进 Task，或者被 await 链条间接驱动时，它才会被事件循环主动推进。常见创建方式包括：

• asyncio.create_task(coro)
• TaskGroup.create_task(coro)

Future

Future 代表未来某个时刻可用的结果。Task 本身就是 Future 的一种更高层形式。很多底层回调式 API 会通过 Future 把稍后完成的状态桥接给协程世界。

从关系上可以这样理解：

• coroutine 描述异步计算
• Task 负责把 coroutine 交给 event loop 调度
• Future 表示一个将来完成的占位结果

event loop 则负责驱动它们的状态变化。

import asyncio
import threading
async def show_running_loop_state():
    loop = asyncio.get_running_loop()
    print(f"loop 类型: {type(loop).__name__}")
    print(f"loop 是否运行中: {loop.is_running()}")
    print(f"当前线程: {threading.current_thread().name}")
    done = loop.create_future()
    def on_soon():
        print("call_soon 回调已执行")
    def on_later():
        print("call_later 回调已执行")
        done.set_result("future 已完成")
    loop.call_soon(on_soon)
    loop.call_later(0.2, on_later)
    result = await done
    print(result)
await show_running_loop_state()

5. 调度语义：await 不是“阻塞”，而是“让出控制权”

这是 event loop 最容易被误解的地方。await 的含义并不是线程卡住等待，而是：当前协程把控制权交还给事件循环，告诉调度器“我暂时无法继续，请先运行其他就绪任务，待条件满足后再恢复我”。

因此，await asyncio.sleep(2) 与 time.sleep(2) 的语义完全不同：

• await asyncio.sleep(2) 会把执行权交回 event loop，其他任务可继续推进
• time.sleep(2) 会直接阻塞当前线程，连 event loop 本身都会停住

这也是为什么把阻塞式函数误写进异步协程，会造成整个事件循环吞吐下降甚至完全失去响应。

6. ready queue、定时器与 I/O 监听

从实现层面说，event loop 至少维护两类重要的待处理工作：

立即执行的回调

通过 call_soon() 提交的回调，会进入 ready queue，在后续迭代尽快执行。

延迟执行的回调

通过 call_later() 或 call_at() 提交的回调，会进入定时器堆；当截止时间到达后，再转入 ready queue 等待执行。

此外，事件循环还会通过 selector、proactor 等机制监听底层 I/O 是否就绪。网络连接、socket 可读写、子进程状态变化等，都可能在 I/O ready 后唤醒相应 Future 或 Task。

应用层开发者虽然未必直接操作这些底层细节，但理解它们有助于解释两个事实：

• asyncio 并不是魔法并发，而是 I/O 驱动的事件分发
• 任务何时恢复，取决于事件是否就绪，而不是简单按代码书写顺序推进

7. Future 如何把回调世界桥接到协程世界

很多底层接口仍以回调形式工作，而协程更适合编写业务逻辑。Future 的价值就在于，它可以作为桥梁，把稍后由别处填入结果的模型暴露给 await。

一个典型过程如下：

1. 创建一个 Future。
2. 把它交给其他机制在未来某个时刻设置结果。
3. 当前协程通过 await future 挂起。
4. 当 future.set_result(...) 或 future.set_exception(...) 被调用时，事件循环恢复等待它的协程。

这也是为什么很多框架底层会先操作 Future，再把更友好的异步接口暴露给上层业务。

8. 低层 loop API 与高层 asyncio API 的边界

在现代 asyncio 编程中，应尽量优先使用高层 API，例如：

• asyncio.run()
• asyncio.create_task()
• asyncio.gather()
• asyncio.TaskGroup()
• asyncio.timeout()
• asyncio.to_thread()

而 loop.create_future()、loop.call_soon()、loop.run_forever()、loop.add_reader() 等 loop 级 API，通常更适合：

• 框架开发
• 自定义运行时整合
• 与底层回调接口对接
• 编写需要显式管理循环生命周期的基础设施代码

工程上一个常见误区是：业务层过早依赖低层 loop 控制接口，结果把代码写得脆弱、难以测试且难以迁移。除非确有必要，否则应让应用代码停留在 asyncio 的高层抽象。

9. 生命周期控制：启动、停止与关闭

如果把 event loop 当作一个长期运行的调度器，那么它的生命周期至少包含三个不同阶段：

启动

循环开始处理回调、定时器与 I/O 事件。

停止

停止意味着结束主循环迭代，并不等价于所有资源都已关闭。例如调用 loop.stop() 后，循环会在适当位置退出，但未必代表执行器、异步生成器、底层资源都已经清理完毕。

关闭

loop.close() 才表示此循环对象不再可用。关闭后不能再继续调度任务或回调。

在普通脚本里，asyncio.run() 已经代替开发者处理了这些细节；但如果你手工管理 loop，就必须严肃地区分 stop 与 close，避免出现：

• 任务尚未完成便关闭循环
• 已关闭循环上继续创建任务
• 后台异常因为未被等待而丢失
• 执行器线程未正确回收

一个更底层、但在脚本中可成立的示例如下：

import asyncio
async def main():
    await asyncio.sleep(1)
    print("done")
loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
    loop.run_until_complete(main())
finally:
    loop.run_until_complete(loop.shutdown_asyncgens())
    loop.close()

这段代码在脚本场景成立，但在 Notebook 中不适合作为直接执行单元，因为 Notebook 自身已经有运行中的事件循环。

10. 取消、异常传播与事件循环的责任边界

event loop 本身不是业务异常处理器，但它负责把异常沿着 Task 和 Future 链条传播到正确的位置。

取消

当调用 task.cancel() 时，事件循环会在下一次合适的切换点向任务注入 CancelledError。这意味着：

• 取消不是立即抢占
• 协程需要运行到下一个可中断点才会感知取消
• 清理逻辑应通过 try/finally 或显式捕获 CancelledError 完成

后台任务异常

如果创建了 Task 却既不 await、也不保存引用，任务内部异常就可能只以 Task exception was never retrieved 的形式暴露。这不是 event loop 的缺陷，而是调用方没有对任务生命周期负责。

因此，生产代码中应遵循两条原则：

• 要么等待任务结果
• 要么明确设计后台任务的异常处理和回收策略

11. 事件循环不是性能银弹

event loop 非常适合 I/O 密集型并发，但并不自动适合 CPU 密集型任务。如果协程内部长时间执行纯 Python 计算而不让出控制权，整个事件循环同样会失去响应。

这类工作应考虑：

• asyncio.to_thread() 把阻塞函数转移到线程池
• run_in_executor() 与执行器配合
• 进程池或专门的任务系统处理重 CPU 工作

换言之，event loop 擅长的是协调等待中的大量任务，而不是并行加速所有计算。

12. 实践建议

围绕 event loop，可以给出几条工程上更稳妥的建议：

1. 应用入口优先使用 asyncio.run()。
2. 业务层尽量依赖高层 asyncio API，不直接操纵底层 loop。
3. 在 Notebook 或框架环境中，优先使用已有运行时提供的 await 机制。
4. 不要在协程里直接调用 time.sleep() 或长时间 CPU 阻塞代码。
5. 对后台任务保留引用，并明确其异常与关闭策略。
6. 只有在桥接回调式 API、实现框架或调试运行时问题时，才深入操作 get_running_loop() 与 loop 对象本身。

13. 总结

从本质上说，asyncio 的 event loop 是一个以事件驱动方式推进异步计算的调度核心。它不直接代表业务逻辑，而是为 coroutine、Task、Future 与 I/O 事件提供统一的执行语义。

真正掌握 event loop，关键不在于记住多少 API，而在于建立一套严格的运行模型：

• 协程在 await 处让出控制权
• Task 由事件循环推进
• Future 代表未来完成的结果
• I/O ready、定时器到期和回调入队共同决定下一步运行什么

一旦这套模型清晰，诸如并发执行、超时控制、取消传播、资源关闭、后台任务治理等问题，都会变得更容易分析和实现。