3、Python并发编程回顾：threading与multiprocessing的局限、GIL的影响、传统并发模型的问题、为什么需要asyncio

在正式进入 asyncio 的世界之前，我们必须先回答一个根本性问题：既然 Python 已经有了 threading 和 multiprocessing 两套并发方案，为什么还需要第三种选择？答案是：这两套方案在特定场景下都存在结构性缺陷。threading 受制于 GIL（全局解释器锁），无法真正利用多核 CPU 做并行计算；multiprocessing 虽然绕开了 GIL，却引入了高昂的进程通信与内存开销。而面对 I/O 密集型任务——例如网络请求、文件读写、数据库查询——传统线程模型还会因为线程切换和阻塞等待浪费大量 CPU 时间。本章将系统梳理这些局限，并引出 asyncio 作为事件驱动型并发方案的核心价值。

3.1 threading 的局限：GIL 与线程切换的双重困境

核心原理：GIL 如何限制多线程并行

CPython 解释器内部维护着一个全局互斥锁——GIL（Global Interpreter Lock）。它的存在使得任何时刻只有一个线程能够执行 Python 字节码。这意味着，即使你的机器有 8 核 CPU，使用 threading 创建 8 个线程执行纯计算任务，实际效果也等同于单线程串行执行。GIL 的引入是为了简化 CPython 的内存管理（特别是引用计数机制），但它直接牺牲了多线程并行能力。

需要特别注意的是，GIL 并非完全禁止并发。当线程执行 I/O 操作（如 socket.recv()、time.sleep()、文件读写）时，GIL 会被释放，允许其他线程运行。因此，threading 对于 I/O 密集型任务仍然有效——它能让 CPU 在等待 I/O 期间切换到其他线程执行任务，从而提升整体吞吐量。但对于 CPU 密集型任务（如数值计算、图像处理），threading 不仅无法加速，反而会因为线程切换和 GIL 竞争导致性能下降。

判断方法：何时该放弃 threading

案例拆解：一个典型的线程池陷阱

假设我们需要从 1000 个 URL 下载网页内容。使用 ThreadPoolExecutor(max_workers=50) 是一个常见做法。初始现象是：程序确实同时发起了 50 个请求，但总耗时并没有比 10 个线程快多少。进一步分析发现，每个请求的响应时间约 200ms，50 个线程并发时，理论上 1000 个请求应该约 4 秒完成（1000/50 × 0.2s），但实际耗时却接近 8 秒。

深入排查后发现两个问题：第一，线程切换开销——每个线程在等待响应时，GIL 被释放，但线程调度本身需要时间；第二，DNS 解析和连接建立阶段也占用 CPU 时间。更关键的是，当线程数超过 CPU 核心数后，线程切换成本急剧上升。最终我们改用 asyncio 实现，使用 aiohttp 发起异步请求，1000 个请求在 2 秒内全部完成——因为 asyncio 在单线程内通过事件循环管理所有 I/O 操作，完全没有线程切换开销。

3.2 multiprocessing 的代价：进程隔离与通信开销

核心原理：绕过 GIL 的代价

multiprocessing 通过创建独立进程来绕过 GIL——每个进程拥有独立的 Python 解释器和内存空间，因此可以真正并行利用多核 CPU。对于 CPU 密集型任务，multiprocessing 是 threading 的合理替代方案。然而，这种设计引入了新的问题：进程间通信（IPC）变得复杂且昂贵。

进程间无法直接共享内存对象，必须通过 Queue、Pipe、Manager 或共享内存（shared_memory）等方式传递数据。每次 IPC 都需要序列化和反序列化（pickle），这在大数据量场景下开销显著。此外，进程的创建和销毁比线程昂贵得多——一个进程的启动需要复制解释器环境、分配独立内存空间，耗时通常在毫秒级甚至更高。

操作流程：multiprocessing 的典型使用模式

from multiprocessing import Process, Queue

def worker(q, data):
    result = data * 2  # 模拟 CPU 密集计算
    q.put(result)

if __name__ == '__main__':
    q = Queue()
    processes = []
    for i in range(4):
        p = Process(target=worker, args=(q, i))
        p.start()
        processes.append(p)
    for p in processes:
        p.join()
    results = [q.get() for _ in range(4)]
    print(results)  # [0, 2, 4, 6]

这段代码展示了 multiprocessing 的基本流程：创建进程 → 启动 → 等待完成 → 收集结果。但注意，Queue 的 put 和 get 操作本身是阻塞的，且涉及序列化开销。如果任务本身是 I/O 密集型，multiprocessing 的优势完全无法发挥，反而会因为进程创建和 IPC 开销导致性能远不如 threading 或 asyncio。

常见误区与总结

另一个常见误区是过度使用 Manager 对象共享复杂数据结构。Manager 通过代理对象实现跨进程访问，但每次属性访问都涉及 IPC 通信，性能极差。如果确实需要共享数据，应优先使用 multiprocessing.shared_memory 或 Array/Value 等底层机制。

3.3 传统并发模型的通病：阻塞、回调地狱与资源浪费

核心原理：同步阻塞模型的效率瓶颈

无论是 threading 还是 multiprocessing，其底层 I/O 模型默认是同步阻塞的。当线程执行 socket.recv() 或 file.read() 时，线程会进入阻塞状态，直到数据就绪。在阻塞期间，线程不执行任何操作，但操作系统仍然需要为其维护上下文。如果同时有 1000 个线程都在等待 I/O，操作系统需要频繁进行上下文切换，每次切换约消耗 1-10 微秒。虽然单次切换看似微不足道，但在高并发场景下，切换开销会迅速累积。

更严重的是，阻塞模型导致 CPU 利用率低下。当线程等待 I/O 时，CPU 核心处于空闲状态，但其他线程又无法利用这个空闲核心——因为线程切换本身需要时间，且 GIL 限制了线程并行。最终结果是：系统看似“忙碌”，但实际有效计算时间占比很低。

回调地狱：非阻塞模型的另一极端

为了解决阻塞问题，部分开发者转向非阻塞 I/O + 回调函数。例如使用 selectors 模块或第三方库 twisted。这种模型下，I/O 操作立即返回，当数据就绪时通过回调通知。但回调模型很快暴露出可读性问题：嵌套回调导致代码难以阅读和维护，错误处理分散在多个回调中，调试困难。

# 回调地狱示例（伪代码）
def fetch_data(url, on_success, on_error):
    socket.connect(url, lambda: 
        socket.send_request(url, lambda response:
            parse_response(response, lambda data:
                save_to_db(data, on_success, on_error))))

# 三层嵌套已经难以阅读，实际场景可能嵌套 5-10 层

这种“回调地狱”使得代码逻辑支离破碎，异常处理难以统一，测试也变得极其困难。asyncio 的协程模型正是为了解决这个问题而设计——它允许你用同步的写法实现异步逻辑，同时保持代码的线性可读性。

案例拆解：一个 Web 爬虫的三种实现对比

从对比中可以看出，asyncio 在 I/O 密集型任务中表现最优。它不仅耗时最短，而且代码可读性高——协程函数看起来就像同步函数，但内部通过 await 实现非阻塞等待。CPU 利用率也更高，因为事件循环在等待 I/O 时不会空转，而是立即切换到其他可执行任务。

3.4 为什么需要 asyncio：事件驱动模型的优势

核心原理：单线程事件循环

asyncio 的核心是一个事件循环（Event Loop）。它维护一个任务队列，每个任务是一个协程（coroutine）。事件循环不断检查哪些协程可以继续执行（例如 I/O 已完成、定时器已到期），然后调度它们运行。协程通过 await 挂起自身，将控制权交还给事件循环，等待某个事件发生后恢复执行。

这种模型的关键优势在于：单线程内实现高并发，无需线程切换，无需锁机制。因为所有协程都在同一个线程中交替执行，不存在数据竞争问题，自然也不需要加锁。协程的切换开销极小（约 1 微秒），远低于线程切换（约 10 微秒）和进程切换（约 100 微秒）。

判断方法：什么场景应该选择 asyncio

• 高并发 I/O 密集型任务：如 Web 服务器、爬虫、消息队列消费者、API 网关。当并发连接数超过 1000 时，线程模型会因资源耗尽而崩溃，asyncio 可以轻松应对数万并发。
• 需要精细控制并发流程：asyncio 提供了 Semaphore、Event、Condition 等同步原语，可以精确控制并发度。
• 微服务架构中的内部调用：服务间频繁进行 HTTP/gRPC 调用，使用 asyncio 可以显著降低延迟。
• 不适合的场景：CPU 密集型任务（应使用 multiprocessing）、需要利用多核的场景（应结合 asyncio + multiprocessing）。

实战场景：从 threading 迁移到 asyncio

假设我们有一个消息推送服务，需要同时维护 5000 个 WebSocket 连接。使用 threading 时，每个连接需要一个线程，5000 个线程导致内存占用超过 2GB（每个线程默认栈空间 8MB），且线程切换开销巨大。迁移到 asyncio 后，单线程即可管理所有连接，内存占用降至 200MB 以内，且延迟降低 50%。

迁移的关键步骤包括：将阻塞 I/O 替换为异步库（如 websockets 替代 socket）、将 time.sleep() 替换为 await asyncio.sleep()、将回调函数重构为协程函数。虽然初期需要学习新 API，但代码结构更清晰，扩展性更好。

常见误区与复盘

一个常见误区是认为 asyncio 能加速所有代码。实际上，如果协程内部包含 CPU 密集计算（如循环 1 亿次），事件循环会被阻塞，其他协程无法运行。此时需要将计算任务交给 asyncio.to_thread() 或 ProcessPoolExecutor 处理。另一个误区是忘记在协程中使用异步库——如果在协程中调用 requests.get()（同步阻塞），整个事件循环都会被阻塞，并发性能归零。