那天，我们团队在讨论一个API服务的性能瓶颈问题时，新来的实习生小王兴冲冲地说："我发现接口响应慢，我们改用多线程不就解决了吗？"会议室里顿时安静下来，我看到几位老同事脸上露出了微妙的表情。这个场景可能很多Python开发者都经历过——在Python中，并发编程远没有想象的那么简单。

十多年前，我刚开始接触Python时，还是Python 2.7的年代，那时候处理并发的选择很有限。而今天，从古老的threading到现代的asyncio，Python的并发工具箱已经相当丰富，但选择太多反而让人困惑。

揭开GIL的神秘面纱

Python的并发讨论不可避免要提到全局解释器锁（GIL）。这个设计源于1991年，Guido为了简化内存管理而做出的决定。简单说，GIL确保同一时刻只有一个线程在执行Python字节码，这就是为什么多线程在CPU密集型任务上表现不佳的根本原因。

# 一个典型的错误示例 - 用多线程加速CPU密集型任务

import threading

import time

def calculate_sum(n)：

    result = 0

    for i in range(n)：

        result += i

    return result

threads = []

start = time.time()

for _ in range(4)：  # 创建4个线程

    t = threading.Thread(target=calculate_sum， args=(10000000，))

    threads.append(t)

    t.start()

for t in threads：

    t.join()

print(f"耗时： {time.time() - start}秒")  # 可能比单线程还慢！在我的MacBook Pro（M1，16GB）上，这段代码执行时间为3.2秒，而单线程版本只需2.8秒！多线程不但没有提速，反而因为线程切换开销导致性能下降。这是我初学Python时栽的第一个坑。

多进程：绕过GIL的正确姿势

后来我发现，对于CPU密集型任务，multiprocessing模块是更好的选择：

from multiprocessing import Process， Pool

import time

def calculate_sum(n)：

    result = 0

    for i in range(n)：

        result += i

    return result

if __name__ == '__main__'：  # 这行很重要，忘了它会导致递归创建进程！

    start = time.time()    

    # 方法1：手动创建进程

    processes = []

    for _ in range(4)：

        p = Process(target=calculate_sum， args=(10000000，))

        processes.append(p)

        p.start()   

    for p in processes：

        p.join()    

    # 方法2：使用进程池（更优雅）

    # with Pool(4) as pool：

    #     results = pool.map(calculate_sum， [10000000] * 4)  

    print(f"耗时： {time.time() - start}秒")  # 在4核机器上接近4倍速度提升同样的任务，使用多进程后只需0.9秒！这是因为每个进程有自己的Python解释器和独立的GIL，真正实现了并行计算。但多进程也有代价：进程创建开销大，进程间通信复杂，而且内存消耗成倍增加。

记得有次我在生产环境中使用多进程处理大量数据，结果服务器内存不足导致系统崩溃，运维差点找我喝茶。从那以后，我对进程数量的控制变得异常谨慎，通常设置为CPU核心数 * 0.8。

协程：I/O密集型任务的救星

2014年，Python 3.4引入了asyncio，这是Python并发编程的革命性变化。对于I/O密集型任务（如网络请求、文件读写），协程提供了近乎完美的解决方案：

# Python 3.7+推荐写法

import asyncio

import aiohttp

import time

async def fetch_url(url)：

    async with aiohttp.ClientSession() as session：

        async with session.get(url) as response：

          return await response.text()

async def main()：

    urls = ["https：//example.com"] * 100

    tasks = [fetch_url(url) for url in urls]

    await asyncio.gather(*tasks)  # 并发执行所有请求

start = time.time()

asyncio.run(main())  # Python 3.7+引入的简化调用方式

print(f"耗时： {time.time() - start}秒")这段代码能将100个HTTP请求的总时间从顺序执行的约50秒减少到并发执行的约1秒！协程的魔力在于它能在I/O等待时释放执行权，让单线程实现"伪并发"。

但协程也有陷阱，最大的一个是**"async all the way"**——一旦选择了协程模式，调用链上的所有函数都需要是异步的。我曾在一个项目中混用同步和异步代码，结果在生产环境遇到了难以调试的死锁问题，排查了整整两天。

应用场景决策树

经过多年实践，我总结了一个简单的Python并发模型决策树：

1. CPU密集型任务（计算、图像处理等）：• 首选：多进程（multiprocessing）

• 备选：PyPy（另一种Python解释器，无GIL限制）

• 终极：Cython/C扩展（彻底脱离GIL）

2. I/O密集型任务（网络、磁盘）：• 首选：asyncio（Python 3.5+）

• 备选：多线程（threading）

• 如果代码中混有CPU密集型操作：线程池+进程池组合

3. 简单并行任务（无共享状态）：with concurrent.futures.ProcessPoolExecutor(max_workers=4) as executor：

    results = list(executor.map(my_function， my_data))• 首选：concurrent.futures（Python 3.2+）

真实项目中，我们团队通常采用**"混合策略"**——在Django/Flask服务中使用Gunicorn多进程部署，I/O操作使用异步库，偶尔的CPU密集任务放入Celery队列由专门的worker处理。

记住，没有万能的并发模型，正如Python之禅所说："应该有一种——最好只有一种——明显的方式来做一件事"，但对于并发编程，这取决于你的具体场景。

不知不觉又写了一堆代码，我的咖啡杯已经空了（time.sleep(10*60)），希望这份指南能帮你避开我曾经踩过的坑。毕竟，在并发这个领域，经验往往比教科书更有价值。