2、异步编程基础：同步与异步、阻塞与非阻塞、并发与并行、进程线程协程对比、异步编程的适用场景
在正式进入 Python Asyncio 的语法与 API 之前，必须先厘清一组极易混淆的核心概念。很多开发者在使用 Asyncio 时感到困惑，根源往往不在于 API 本身，而在于对“同步/异步”“阻塞/非阻塞”“并发/并行”以及“进程/线程/协程”这几组术语的理解存在偏差。本章将从底层原理出发，逐一拆解这些概念，并通过对比表格、判断路径和实战场景，帮助你建立一套清晰的异步编程心智模型。只有真正理解了这些基础，后续学习事件循环、任务调度和底层 API 时才能事半功倍。
2.1 同步与异步：调用者视角的等待语义
核心原理：同步（Synchronous）与异步（Asynchronous）描述的是调用者发起操作后，是否需要等待该操作完成才能继续执行后续代码。同步调用中，调用者发起请求后会一直等待，直到被调用方返回结果；异步调用中，调用者发起请求后立即返回，继续执行后续逻辑，被调用方在完成后通过回调、事件或 Future 对象通知调用者。需要特别强调的是，同步/异步与阻塞/非阻塞是两组正交的概念，但实践中经常被混用。例如，一个同步接口可能以非阻塞方式实现（轮询状态），而一个异步接口也可能在内部以阻塞方式等待某个资源。
判断方法：判断一段代码是同步还是异步，最直接的方法是观察函数调用后是否立即返回。如果调用后程序必须等待结果才能继续，就是同步；如果调用后程序立即继续执行，结果稍后通过回调或 await 获取，就是异步。在 Python 中，async def 定义的协程函数是异步的，而普通 def 函数是同步的。但要注意，异步函数内部如果调用了同步阻塞库（如 requests），整个事件循环仍会被阻塞，这属于“异步框架中的同步陷阱”。
| 维度 | 同步 | 异步 |
|---|---|---|
| 调用返回时机 | 等待操作完成 | 立即返回 |
| 结果获取方式 | 直接作为返回值 | 回调 / Future / await |
| 代码可读性 | 线性直观 | 需要理解事件驱动模型 |
| 典型场景 | 脚本、简单 CLI | 网络服务、GUI 事件循环 |
await 关键字是异步编程的“暂停点”。当协程执行到 await 时，它会主动让出控制权给事件循环，而不是阻塞整个线程。这是理解 Asyncio 高效性的关键——协程的切换是协作式的，由开发者显式控制。
2.2 阻塞与非阻塞：线程状态的微观视角
核心原理：阻塞（Blocking）与非阻塞（Non-blocking）描述的是调用期间，当前线程是否会被挂起（进入等待状态）。阻塞调用会让线程进入睡眠状态，直到 I/O 操作完成或超时，期间线程无法执行任何其他任务；非阻塞调用则立即返回，线程可以继续执行其他指令，但需要反复检查操作是否完成（轮询）或依赖事件通知。在操作系统层面，阻塞调用会触发线程上下文切换，这是昂贵的操作；非阻塞调用则避免了这种切换，但需要额外的状态管理。
操作流程：在实际开发中，判断一个函数是否阻塞，最可靠的方法是查看其底层实现是否调用了系统调用（如 read()、write()、sleep()）并等待其返回。Python 中常见的阻塞操作包括：time.sleep()、requests.get()、socket.recv()（默认模式）、文件读写（磁盘 I/O）。非阻塞操作则包括：socket.setblocking(False) 后的 recv()、select.select()、asyncio.sleep()。Asyncio 的核心价值之一，就是将这些底层非阻塞 I/O 封装成协程友好的接口，让开发者无需直接处理轮询逻辑。
asyncio.gather() 并发执行三个协程，总耗时 ≈ max(请求1, 请求2, 请求3) ≈ 2 秒。这是因为在等待网络响应时，事件循环会切换到其他协程执行，线程本身从未被阻塞。但要注意，如果这三个请求使用的是 requests 库（同步阻塞），即使放在协程中，事件循环也会被第一个请求阻塞，无法切换到其他协程，总耗时仍然是 6 秒。这就是为什么 Asyncio 必须搭配非阻塞 I/O 库（如 aiohttp）使用。
asyncio.to_thread() 或 loop.run_in_executor() 将其提交到线程池执行，避免阻塞事件循环。
2.3 并发与并行：任务执行的时间重叠方式
核心原理：并发（Concurrency）与并行（Parallelism）是经常被混淆的概念。并发是指多个任务在同一时间段内交替执行，但在任意时刻只有一个任务在运行（单核 CPU 上）；并行是指多个任务在同一时刻同时执行，这需要多核 CPU 或多台机器。并发是逻辑上的“同时”，并行是物理上的“同时”。Asyncio 实现的是并发而非并行——它通过事件循环在单线程内调度多个协程，利用 I/O 等待时间切换任务，从而提升吞吐量，但不会利用多核 CPU 的计算能力。
判断方法：判断一个程序是并发还是并行，可以观察其执行时的 CPU 利用率。如果程序在单核 CPU 上运行，且多个任务交替执行，就是并发；如果程序在多核 CPU 上运行，且多个任务同时占用不同核心，就是并行。Python 中，多线程（受 GIL 限制）和多协程实现的是并发，多进程（multiprocessing）可以实现并行。对于 CPU 密集型任务，Asyncio 没有优势，甚至因为协程切换开销而更慢；对于 I/O 密集型任务，Asyncio 的并发模型能显著提升效率。
| 维度 | 并发 | 并行 |
|---|---|---|
| 执行方式 | 交替执行（时间片轮转） | 同时执行（多核并行） |
| 硬件要求 | 单核即可 | 必须多核 |
| 核心目标 | 提高吞吐量（I/O 利用率） | 提高计算速度（CPU 利用率） |
| Python 实现 | 线程、协程 | 多进程 |
| 适用场景 | 网络请求、文件 I/O | 图像处理、科学计算 |
2.4 进程、线程与协程：执行载体的对比
核心原理：进程（Process）是操作系统资源分配的最小单位，拥有独立的地址空间；线程（Thread）是 CPU 调度的最小单位，共享进程内的地址空间；协程（Coroutine）是用户态调度的执行单元，由程序自身控制切换，不涉及内核态切换。三者的核心区别在于资源隔离级别、切换开销和通信方式。进程间通信（IPC）需要管道、消息队列等机制，开销最大；线程间通信通过共享内存，但需要加锁保护；协程间通信通过事件循环和 Future 对象，无需加锁（单线程内天然线程安全）。
对比分析：在 Python 中，由于 GIL（全局解释器锁）的存在，多线程无法利用多核 CPU 进行并行计算，因此线程在 Python 中的主要价值是处理 I/O 密集型任务（GIL 在 I/O 等待时会释放）。协程则更进一步，它在单线程内实现了协作式调度，切换开销比线程小一个数量级（约 1-2 微秒 vs 10-20 微秒）。进程是唯一能突破 GIL 限制的方案，但进程创建和切换开销最大，且不适合大量并发连接。
| 维度 | 进程 | 线程 | 协程 |
|---|---|---|---|
| 调度方式 | 内核调度 | 内核调度 | 用户态调度（事件循环） |
| 切换开销 | 高（约 10-100μs） | 中（约 10-20μs） | 低（约 1-2μs） |
| 内存占用 | 独立地址空间（数 MB） | 共享地址空间（约 1MB 栈） | 共享地址空间（约几 KB） |
| 通信方式 | IPC（管道/队列/共享内存） | 共享内存 + 锁 | Future / 事件循环 |
| GIL 影响 | 无（独立解释器） | 受 GIL 限制 | 受 GIL 限制（但 I/O 等待不占用） |
| 适用场景 | CPU 密集型、多核利用 | I/O 密集型（少量连接） | I/O 密集型（高并发连接） |
2.5 异步编程的适用场景与选型决策
核心原理：异步编程并非万能银弹，它适用于I/O 密集型且并发量高的场景，但在 CPU 密集型场景中反而会因调度开销而降低性能。选择异步编程前，需要评估任务的性质：如果任务大部分时间在等待外部资源（网络、磁盘、数据库），异步编程能显著提升吞吐量；如果任务大部分时间在计算（循环、数学运算），则应选择多进程或直接使用同步代码。
选型决策流程：首先判断任务类型——CPU 密集型选择多进程，I/O 密集型进入下一步；然后评估并发量——并发连接数超过 100 时优先考虑 Asyncio，低于 100 时多线程即可；最后考虑开发成本——Asyncio 的学习曲线较陡，如果团队不熟悉异步编程，且并发量要求不高，使用线程池 + 同步代码可能是更务实的选择。此外，还要考虑生态兼容性：如果项目依赖的第三方库不支持异步（如某些数据库驱动），需要评估是否值得引入异步替代方案。
time.sleep()、使用 asyncio.create_task() 时务必保存任务引用等。