搞 Python 这么多年要说最能区分“会写”和“真懂”的一道坎就是多任务编程。很多人单线程代码写得很顺一遇到高并发、大量 IO 阻塞、多核 CPU 利用率上不去就开始在进程、线程、协程之间反复横跳。这篇我来把 Python 多任务的底层逻辑和实操细节一次性讲透重点讲清楚三种并发模型各自适合什么场景、代码怎么落地、踩坑怎么排查。无论你是刚接触异步开发的新手还是正在优化服务稳定性、写爬虫或做数据处理的老手这篇都能给你一套可以直接用的参考方案。1. 多任务编程的整体设计思路与选型1.1 多任务到底解决什么问题先说一个容易被忽略的事实大多数人一开始并不需要多任务。Python 代码慢很多时候是算法差、IO 频繁、循环重复而不是不会用并发。我见过不少项目一上来就开十几个线程结果不仅没提速反而因为锁竞争和上下文切换变得更慢。所以在谈进程、线程、协程之前最该问自己的是瓶颈到底在 CPU 还是 IO。如果一段程序在等待网络响应、读写文件、查询数据库这种叫 IO 密集型任务CPU 大部分时间是空闲的。这时候用多任务可以让等待期间去执行其他任务整体吞吐量成倍上升。如果是做图像处理、数值计算、视频编解码这类 CPU 密集型任务重点则是如何让多个 CPU 核心同时工作这就要靠多进程。理解了这个区分后面选型才不会跑偏。多任务编程本质上是在“榨干”资源单核 CPU 上用时间片换来“同时运行”的错觉多核 CPU 上就能真正并行。Python 里这三种方案各有脾气没有银弹只有适配。1.2 进程、线程、协程的关系与取舍把抽象概念落到生活类比里会清晰很多。进程可以理解成一条独立的生产线有自己的厂房、机器和原料库。生产线之间互不干扰想通信得靠外部传送带成本高但稳定性强一条线崩了不会影响其他线。线程是厂房里的工人共享厂房里的设备和原料。工人们之间交流方便但如果你正在用的工具别人也要用就得排队等锁。问题在于 Python 的线程有个著名的 GIL全局解释器锁让同一时刻真正执行 Python 字节码的线程只能有一个。所以多个线程对 CPU 密集型任务几乎没有帮助但对付 IO 密集型任务依然有效因为线程在等待 IO 时会释放 GIL。协程是在单线程内部实现的“超轻量级工人”。它不依赖操作系统调度而是由程序在遇到 IO 等待时主动让出控制权去做别的任务。因为切换代价极小所以可以创建成千上万个协程这是线程做不到的。协程适合海量连接、高并发 IO 服务但不适合 CPU 密集型逻辑。使用场景对比可以看下面这张表维度进程线程协程资源占用高独立内存空间中共享同一进程资源低单线程内调度切换开销大中等极小适用任务CPU 密集型、需要隔离的任务IO 密集型但数量不宜过多海量 IO 并发高并发网络服务Python 中的限制受进程数量限制启动成本高受 GIL 限制CPU 密集型提升有限受单核限制依赖事件循环数据共享需要特殊通信机制直接用共享对象但需加锁天然单线程无竞争问题1.3 如何根据场景做选型我的习惯是先画一张决策表按任务类型分任务是计算密集、逻辑复杂用多进程。任务是频繁读取网络、磁盘、数据库且并发量不大用多线程。任务是高并发 IO 场景比如 Web 服务、爬虫抓取、消息推送用协程。这里要注意很多场景是混合的。比如一个爬虫程序既要下载几百个 URL又要对每个响应做解析计算。下载是 IO 密集解析计算如果是纯逻辑则可能吃 CPU。我的做法是先用协程做并发请求再把计算量大的部分丢进线程池或进程池让不同的工具干自己擅长的活。说到底多任务编程不是“只用一种”而是组合。选择之后还要考虑项目的复杂度和团队维护成本。协程代码如果设计不好调试起来很痛苦进程模式在 Windows 上要注意入口保护线程模式虽然最熟悉但锁用不好就容易出竞态问题。后续章节我会针对每一种模型给出核心操作方法和避坑经验。2. 核心原理拆解GIL、上下文切换与并发并行2.1 GIL 是 Python 并发绕不开的紧箍咒GIL全局解释器锁是 CPython 解释器里的一个互斥锁。它保证同一时刻只有一个线程在解释器里执行 Python 字节码。这个设计让内存管理变得简单但也让多线程在 CPU 密集型任务上成了摆设。很多初学者会误以为 GIL 会让线程完全不能并行。准确地说GIL 是会在 IO 等待、系统调用、多个指令间隔等情况下释放的。所以线程遇到 IO 阻塞时其他线程就能趁机执行。这就是为什么线程对 IO 密集型任务有效而对计算密集任务无效。我在实际项目里测过一个纯 Python 的死循环开四个线程跑总耗时比单线程还差。因为 GIL 频繁切换反而增加了调度成本。遇到这种情况要么改用多进程要么把核心计算交给 C 扩展库比如 NumPy 这类底层释放 GIL 的库。2.2 进程与线程的底层差异进程是操作系统资源分配的最小单位线程是 CPU 调度的最小单位。每个进程有独立的地址空间线程共享进程的地址空间。所以进程之间的变量不能直接访问需要通过队列、管道、共享内存等方式线程则可以直接操作同一个对象但操作时要用锁保证安全。从可靠性角度看一个进程中某个线程死掉可能导致整个进程崩溃但其他进程不受影响。从扩展性角度看进程可以利用多核 CPU而线程因为 GIL 限制在 Python 里做不到真正的多核并行。这两点决定了进程在某些场景下无法被线程替代。上下文切换的开销也不同。进程切换需要切换地址空间、页表、缓存等开销大线程切换虽然也要保存寄存器状态但地址空间不变开销相对小协程切换完全在用户态进行只需要保存少量变量开销最小。这个差异直接影响你能创建的并发数量上限。2.3 协程的调度模型事件循环协程依赖事件循环event loop来调度。事件循环是一个无限循环它的工作是维护一个任务队列取出需要执行的任务遇到 IO 等待就让出等 IO 完成后再回来继续。用生活类比事件循环就像一个前台接待员手里同时有很多请求谁准备好资料了就处理谁而不是死死地等一个人把资料拿全。程序里的 async 函数会被包装成 TaskTask 挂在事件循环上。遇到await时如果被等待的对象还没准备好协程就挂起事件循环立刻切换去执行别的 Task。这个模型让协程可以单线程处理上万个连接。每个连接只需要保存协程的上下文极轻量。但也正因为单线程协程里如果有一段纯 CPU 密集计算没写await整条事件循环就会被卡住所有其他任务都跟着停。这是协程编程最需要注意的坑。2.4 并发 vs 并行概念别搞混很多人把 concurrency 和 parallelism 混为一谈。并发是“同时处理多个任务”但不一定同一时刻执行可能是交替执行并行是“同一时刻真正执行多个任务”需要多核或多 CPU。协程和线程在单核上实现的是并发多进程在多核上可以实现并行。这个区分很重要因为一个任务从“能响应”到“执行的更快”可能需要对模型做完全不同的改变。比如一个 Web 服务用协程能做到高并发响应但如果某个请求内部有大量计算即便协程再多这个请求依然慢。这时候要在协程里把计算任务丢给进程池让其他核心真正跑起来。理解并发和并行等于理解了“快”和“活”的区别。协程擅长让系统活着进程擅长让系统更快线程则夹在中间。3. 实操线程与进程的使用与细节3.1 用 threading 创建线程的完整姿势Python 标准库threading是最直观的多线程入口。基本流程是先定义一个函数然后创建Thread对象调用start()最后用join()等待线程结束。import threading import time def worker(name, delay): print(f线程 {name} 开始) time.sleep(delay) print(f线程 {name} 结束) t1 threading.Thread(targetworker, args(A, 2)) t2 threading.Thread(targetworker, args(B, 1)) t1.start() t2.start() t1.join() t2.join() print(主线程结束)需要注意几点args必须传元组所以我写(A, 2)少写逗号会变成字符串容易踩坑。join()是必需的否则主线程提前退出子线程可能被直接终止。不要通过改名run()来执行逻辑除非你自定义子类直接用target更明确。如果想让线程循环执行特定任务可以用threading.Timer做延时任务或者写个while循环加个退出事件。一种常见的模式是用threading.Event控制线程停止而不是直接调用terminate()因为 Python 线程没有强制终止的方法。3.2 线程锁与线程安全原子操作不是免费的共享变量是线程编程的经典坑。看一个例子import threading counter 0 def increment(): global counter for _ in range(100000): counter 1 threads [threading.Thread(targetincrement) for _ in range(4)] for t in threads: t.start() for t in threads: t.join() print(counter) # 期望 400000实际大概率小于这个数为什么结果不对因为counter 1不是原子操作它分成取值、加法、赋值三步。多个线程交错执行最后赋值会覆盖前面的结果。解决办法是加锁lock threading.Lock() def increment_safe(): global counter for _ in range(100000): with lock: counter 1用with lock可以确保同一时间只有一个线程执行这段代码。但锁会降低并发度所以锁的粒度越小越好。像这种只保护一个变量的场景也可以用queue.Queue或multiprocessing.Value自带的锁。线程安全的漏洞很难排查所以我的经验是能用不可变数据、能用局部变量就尽量少用共享状态。很多情况下每个线程把结果算完最后集中合并比一堆线程同时改同一个变量要稳得多。3.3 线程池 ThreadPoolExecutor 的正确使用线程池比手动创建线程更推荐因为线程创建和销毁都有成本池可以复用。concurrent.futures.ThreadPoolExecutor是现代 Python 首选。from concurrent.futures import ThreadPoolExecutor, as_completed import time def fetch(url): time.sleep(1) # 模拟网络请求 return f{url} 的结果 urls [url1, url2, url3, url4, url5] with ThreadPoolExecutor(max_workers3) as executor: futures [executor.submit(fetch, url) for url in urls] for future in as_completed(futures): print(future.result())max_workers建议不要开太大。IO 密集虽然可以多开但线程切换和内存占用会随之上升。通常我给普通爬虫任务开 5~10 个给文件读写开 4~8 个。如果单线程里的任务本身很快开太多线程反而会增加调度开销。as_completed()会按完成顺序返回结果适合处理不要求返回顺序的高并发任务。如果必须按输入顺序返回用executor.map()更方便但它会等前面的任务完成返回顺序是固定的。3.4 用 multiprocessing 实现真正的多核并行如果任务是 CPU 密集型绕开 GIL 的正解是multiprocessing。它创建的是独立进程每个进程有独立解释器和内存空间。看一个基础例子from multiprocessing import Process import os def heavy_calc(n): print(f进程 {os.getpid()} 计算 {n}) return n * n if __name__ __main__: ps [Process(targetheavy_calc, args(i,)) for i in range(4)] for p in ps: p.start() for p in ps: p.join()注意if __name__ __main__在 Windows 上多进程需要入口保护否则会递归创建子进程甚至报错。这在 Linux 上不那么严格但写进代码里是统一规范的。多进程之间不共享变量所以生产环境里最常用的通信方式不是直接改变量而是用队列multiprocessing.Queue。主进程派发任务子进程从队列取任务再把结果放回队列。模式如下from multiprocessing import Process, Queue def worker(q_in, q_out): while True: item q_in.get() if item is None: break result item * 2 q_out.put(result) if __name__ __main__: q_in Queue() q_out Queue() p Process(targetworker, args(q_in, q_out)) p.start() for i in range(5): q_in.put(i) q_in.put(None) # 向 worker 发送结束信号 p.join() while not q_out.empty(): print(q_out.get())这里None是常用的哨兵对象用来通知子进程退出。如果不加子进程会一直阻塞在q.get()上进程无法正常结束。3.5 进程池与跨进程数据共享如果任务相对独立用multiprocessing.Pool或concurrent.futures.ProcessPoolExecutor会更优雅。ProcessPoolExecutor 的 API 和线程池几乎一样改一下导入即可from concurrent.futures import ProcessPoolExecutor def square(n): return n ** 2 if __name__ __main__: with ProcessPoolExecutor(max_workers4) as ex: results ex.map(square, range(10)) print(list(results))但要注意进程池里传的参数必须能被 pickle 序列化。自定义类、lambda 函数、局部函数都可能出问题。协程、嵌套函数、某些动态生成的对象都不行。这是新手最常见的问题代码本身没错就是序列化失败。如果确实需要在进程间共享比较复杂的数据multiprocessing.Manager可以提供代理对象比如 Manager 下的 list、dict、Namespace。它是通过独立进程管理的访问速度比队列慢但是方便。对性能要求不高的配置同步、状态统计任务够用。另外进程模式在 Windows 上启动开销很大每次都重新 import 主模块。所以尽量把计算任务放在if __name__ __main__里避免不必要的模块级重复初始化。4. 实操协程与异步编程4.1 async/await 基础语法先甩掉老思想协程让很多习惯了同步思维的人不适因为代码的执行顺序不再是从上到下一字排开。什么函数能await必须是被async def声明的协程函数或者类似 Future/Task 的对象。普通函数里不能使用await。import asyncio async def say_hello(): print(hello) await asyncio.sleep(1) print(world) async def main(): task asyncio.create_task(say_hello()) await task asyncio.run(main())这里最直观的区别是asyncio.sleep(1)不是让整个线程睡 1 秒而是让出控制权事件循环可以执行其他任务。asyncio.run()是 Python 3.7 后的入口它负责创建事件循环、运行主协程、关闭事件循环。记住一条铁律协程函数只有在被调度后才会真正执行。只调用say_hello()得到的是一个协程对象不会打印任何内容。必须用await、create_task()或asyncio.run()包一层。4.2 用 gather 并发执行多个协程最常用的并发执行方式是asyncio.gather()。它接收一组可等待对象并发的执行它们然后按传入顺序返回结果。import asyncio async def fetch_data(name, delay): await asyncio.sleep(delay) return f{name} done async def main(): results await asyncio.gather( fetch_data(A, 2), fetch_data(B, 1), fetch_data(C, 3), ) print(results) asyncio.run(main())三个协程会并发执行总耗时接近 3 秒而不是 6 秒。gather在结果顺序上是稳定的但它内部是并发调度。如果其中一个任务抛异常整个gather默认会向上抛异常并取消其他任务。如果希望一个任务挂了不影响其他任务可以传入return_exceptionsTrue这样异常会作为结果返回而不是直接中断。除了gatherasyncio.wait和asyncio.as_completed也常用。gather适合聚合结果as_completed适合按完成顺序处理流式任务。我在写多 URL 请求时经常把as_completed配create_task用类似线程池里的as_completed。4.3 在协程中正确执行阻塞操作这是协程编程最容易翻车的地方。如果在协程里写了time.sleep(1)事件循环会被卡住整整 1 秒哪怕还有其他 IO 任务等着。因为time.sleep是同步阻塞函数不会让出控制权。同样的道理适用于requests.get()、open().read()这类同步 IO。正确做法是使用asyncio.to_thread或把阻塞操作放到线程池。import asyncio import time def blocking_read(): time.sleep(2) return data async def main(): data await asyncio.to_thread(blocking_read) print(data) asyncio.run(main())asyncio.to_thread是 Python 3.9 后的好帮手会把阻塞函数放到线程池里执行同时让协程暂停事件循环继续服务其他任务。但要注意如果创建大量to_thread底层还是一个线程池不要以为协程就真的“无极限”了。传统方式是用loop.run_in_executor。在 Python 3.10更推荐asyncio.to_thread这种简洁语法。还有一个选择是直接把同步库换成异步库比如用aiohttp代替requests用aiofiles代替普通文件读。能异步化就异步化性能最好。4.4 协程性能对比到底能省多少很多读者关心协程比线程快多少。实际测试中普通网络请求场景下协程和线程差距不算巨大但协程在“高并发海量连接”场景优势明显。我的经验是当并发量超过几百甚至上千以后线程会因为栈空间和调度开销变得笨重而协程依然游刃有余。每个协程占用内存远远小于线程线程栈默认数百万字节协程栈可能只要几 KB。不过协程并不是万能的它最大的劣势是“传染性”。你用了async def就希望整个调用链都是异步的。项目里如果有老的同步库、第三方 SDK混写会非常别扭。这时候我会谨慎评估是把整个模块重写成异步还是用线程池把同步调用隔离出去。这两种思路都可行但不要一边用async一边到处to_thread否则架构会很混乱。5. 常见问题与排查技巧实录5.1 线程竞争与数据不一致加锁之外还有招线程竞争是我在代码 review 时最常看到的问题。除了维护复杂的锁逻辑一个更简单的思路是让任务彻底无共享。比如把每个线程要处理的数据都做成独立副本线程只操作自己的数据最后用futures.result()或者队列汇总。这样根本不需要锁出错概率大大降低。如果确实需要共享计数器、缓存等尽量用线程安全的容器比如queue.Queue、collections.deque某些操作是原子的、threading.local线程局部变量。threading.local()很值得推荐它可以为每个线程维护独立数据模拟“全局变量但互相隔离”的效果。排查线程问题时先看现象是不是偶发、是否和并发数相关。如果结果随机变基本就是数据竞争。可以先在代码里加上threading.current_thread().name打印每个线程的状态再逐步缩小范围。5.2 进程之间数据传递序列化陷阱多进程最常见的坑是pickle序列化问题。ProcessPoolExecutor的map或submit在提交任务时会把函数和参数序列化后再发给子进程。如果函数是闭包、lambda、带yield的生成器、或者引用了不可序列化对象就会直接报错。解决思路有三种把任务函数定义在模块顶层并且只传基础类型参数。用multiprocessing.Manager提供跨进程容器但性能会下降。实在绕不开繁重共享数据考虑直接改用第三方方案比如把任务数据通过pickle文件或数据库暂存。还有一个容易忽略的问题子进程里的print不一定按顺序出现在终端因为输出流是分开缓冲的。调试时要加flushTrue或者把日志写到文件否则很难看执行路径。5.3 协程卡死、不退出、结果不返回协程程序常见的卡死场景是某个协程迟迟没有await导致事件循环无法执行或者await的是一个永远不会有结果的 Future。排查时先看所有await是否都发生在非阻塞调用上再看任务里有没有死循环。另一个常见问题是“忘了调用asyncio.run或get_event_loop”导致协程对象被创建但从未执行。新手容易把async def main()里的 main 当作普通函数调用控制台只显示RuntimeWarning: coroutine was never awaited。遇到这个警告第一反应就是在前面加asyncio.run()。异步资源也需要手动清理。打开多个网络连接时最好用async with管理会话比如aiohttp.ClientSession。否则事件循环关闭时可能残留连接影响程序退出。在main结束前显式await掉所有 task是更稳妥的习惯。5.4 死锁与排查工具速查死锁多发生在线程或进程之间互相等待锁。比如 A 线程持有锁 1等待锁 2B 线程持有锁 2等待锁 1。这种问题很难用肉眼看出来最好直接上工具。Python 3.10 之后可以通过faulthandler.dump_traceback_later(10)在程序运行 10 秒后自动输出线程栈快速定位卡住的位置。faulthandler是标准库实用性强。另外pysnooper这类调试库也可以打日志生产环境慎用性能开销大。排查步骤我通常这么走用logging记录每个关键锁的 acquire 与 release。观察锁等待时间超过阈值的记录。检查获取多个锁的顺序是否一致。如果有两个线程按相反顺序申请锁就极容易死锁。统一锁顺序、减少锁粒度、用超时锁lock.acquire(timeout3)兜底。5.5 一张速查表进程线程协程怎么选最后附一张我在方案评审时经常用的速查表方便快速定位场景推荐方案理由大量网络请求、长连接协程async aiohttp高并发占用小爬虫抓取几十个 URL线程池ThreadPoolExecutor简单够用兼容同步库图片批量处理、数据计算进程池ProcessPoolExecutor利用多核 CPUCPU 密集 IO 密集混合协程 进程池组合各干各擅长的复杂业务共享全局状态尽量避免必要时加锁共享越少问题越少我个人的习惯是先把“纯 CPU”和“纯 IO”分开然后各自选模型最后再用队列或 Future 把它们串起来。这种方式写出来的代码结构清晰排查问题也方便。多任务编程真正难的不是 API而是思维方式接受并发、接受不确定性、接受调度。很多东西只有自己跑一遍看到计数器错乱、死锁或卡住的瞬间才算真正理解。如果你的项目还停留在单线程我建议从线程池开始改再逐步引入协程。步子大容易折循序渐进最稳。最后再分享一个小技巧无论是写threading、multiprocessing还是asyncio都要想清楚“谁负责等待”和“谁负责退出”。只要把每个任务的进入条件、结束信号、异常处理都写明确并发代码就成功了大半。多任务不是魔法是用规则管理复杂性规则越简单系统越稳。
搞 Python 这么多年要说最能区分“会写”和“真懂”的一道坎就是多任务编程。很多人单线程代码写得很顺一遇到高并发、大量 IO 阻塞、多核 CPU 利用率上不去就开始在进程、线程、协程之间反复横跳。这篇我来把 Python 多任务的底层逻辑和实操细节一次性讲透重点讲清楚三种并发模型各自适合什么场景、代码怎么落地、踩坑怎么排查。无论你是刚接触异步开发的新手还是正在优化服务稳定性、写爬虫或做数据处理的老手这篇都能给你一套可以直接用的参考方案。1. 多任务编程的整体设计思路与选型1.1 多任务到底解决什么问题先说一个容易被忽略的事实大多数人一开始并不需要多任务。Python 代码慢很多时候是算法差、IO 频繁、循环重复而不是不会用并发。我见过不少项目一上来就开十几个线程结果不仅没提速反而因为锁竞争和上下文切换变得更慢。所以在谈进程、线程、协程之前最该问自己的是瓶颈到底在 CPU 还是 IO。如果一段程序在等待网络响应、读写文件、查询数据库这种叫 IO 密集型任务CPU 大部分时间是空闲的。这时候用多任务可以让等待期间去执行其他任务整体吞吐量成倍上升。如果是做图像处理、数值计算、视频编解码这类 CPU 密集型任务重点则是如何让多个 CPU 核心同时工作这就要靠多进程。理解了这个区分后面选型才不会跑偏。多任务编程本质上是在“榨干”资源单核 CPU 上用时间片换来“同时运行”的错觉多核 CPU 上就能真正并行。Python 里这三种方案各有脾气没有银弹只有适配。1.2 进程、线程、协程的关系与取舍把抽象概念落到生活类比里会清晰很多。进程可以理解成一条独立的生产线有自己的厂房、机器和原料库。生产线之间互不干扰想通信得靠外部传送带成本高但稳定性强一条线崩了不会影响其他线。线程是厂房里的工人共享厂房里的设备和原料。工人们之间交流方便但如果你正在用的工具别人也要用就得排队等锁。问题在于 Python 的线程有个著名的 GIL全局解释器锁让同一时刻真正执行 Python 字节码的线程只能有一个。所以多个线程对 CPU 密集型任务几乎没有帮助但对付 IO 密集型任务依然有效因为线程在等待 IO 时会释放 GIL。协程是在单线程内部实现的“超轻量级工人”。它不依赖操作系统调度而是由程序在遇到 IO 等待时主动让出控制权去做别的任务。因为切换代价极小所以可以创建成千上万个协程这是线程做不到的。协程适合海量连接、高并发 IO 服务但不适合 CPU 密集型逻辑。使用场景对比可以看下面这张表维度进程线程协程资源占用高独立内存空间中共享同一进程资源低单线程内调度切换开销大中等极小适用任务CPU 密集型、需要隔离的任务IO 密集型但数量不宜过多海量 IO 并发高并发网络服务Python 中的限制受进程数量限制启动成本高受 GIL 限制CPU 密集型提升有限受单核限制依赖事件循环数据共享需要特殊通信机制直接用共享对象但需加锁天然单线程无竞争问题1.3 如何根据场景做选型我的习惯是先画一张决策表按任务类型分任务是计算密集、逻辑复杂用多进程。任务是频繁读取网络、磁盘、数据库且并发量不大用多线程。任务是高并发 IO 场景比如 Web 服务、爬虫抓取、消息推送用协程。这里要注意很多场景是混合的。比如一个爬虫程序既要下载几百个 URL又要对每个响应做解析计算。下载是 IO 密集解析计算如果是纯逻辑则可能吃 CPU。我的做法是先用协程做并发请求再把计算量大的部分丢进线程池或进程池让不同的工具干自己擅长的活。说到底多任务编程不是“只用一种”而是组合。选择之后还要考虑项目的复杂度和团队维护成本。协程代码如果设计不好调试起来很痛苦进程模式在 Windows 上要注意入口保护线程模式虽然最熟悉但锁用不好就容易出竞态问题。后续章节我会针对每一种模型给出核心操作方法和避坑经验。2. 核心原理拆解GIL、上下文切换与并发并行2.1 GIL 是 Python 并发绕不开的紧箍咒GIL全局解释器锁是 CPython 解释器里的一个互斥锁。它保证同一时刻只有一个线程在解释器里执行 Python 字节码。这个设计让内存管理变得简单但也让多线程在 CPU 密集型任务上成了摆设。很多初学者会误以为 GIL 会让线程完全不能并行。准确地说GIL 是会在 IO 等待、系统调用、多个指令间隔等情况下释放的。所以线程遇到 IO 阻塞时其他线程就能趁机执行。这就是为什么线程对 IO 密集型任务有效而对计算密集任务无效。我在实际项目里测过一个纯 Python 的死循环开四个线程跑总耗时比单线程还差。因为 GIL 频繁切换反而增加了调度成本。遇到这种情况要么改用多进程要么把核心计算交给 C 扩展库比如 NumPy 这类底层释放 GIL 的库。2.2 进程与线程的底层差异进程是操作系统资源分配的最小单位线程是 CPU 调度的最小单位。每个进程有独立的地址空间线程共享进程的地址空间。所以进程之间的变量不能直接访问需要通过队列、管道、共享内存等方式线程则可以直接操作同一个对象但操作时要用锁保证安全。从可靠性角度看一个进程中某个线程死掉可能导致整个进程崩溃但其他进程不受影响。从扩展性角度看进程可以利用多核 CPU而线程因为 GIL 限制在 Python 里做不到真正的多核并行。这两点决定了进程在某些场景下无法被线程替代。上下文切换的开销也不同。进程切换需要切换地址空间、页表、缓存等开销大线程切换虽然也要保存寄存器状态但地址空间不变开销相对小协程切换完全在用户态进行只需要保存少量变量开销最小。这个差异直接影响你能创建的并发数量上限。2.3 协程的调度模型事件循环协程依赖事件循环event loop来调度。事件循环是一个无限循环它的工作是维护一个任务队列取出需要执行的任务遇到 IO 等待就让出等 IO 完成后再回来继续。用生活类比事件循环就像一个前台接待员手里同时有很多请求谁准备好资料了就处理谁而不是死死地等一个人把资料拿全。程序里的 async 函数会被包装成 TaskTask 挂在事件循环上。遇到await时如果被等待的对象还没准备好协程就挂起事件循环立刻切换去执行别的 Task。这个模型让协程可以单线程处理上万个连接。每个连接只需要保存协程的上下文极轻量。但也正因为单线程协程里如果有一段纯 CPU 密集计算没写await整条事件循环就会被卡住所有其他任务都跟着停。这是协程编程最需要注意的坑。2.4 并发 vs 并行概念别搞混很多人把 concurrency 和 parallelism 混为一谈。并发是“同时处理多个任务”但不一定同一时刻执行可能是交替执行并行是“同一时刻真正执行多个任务”需要多核或多 CPU。协程和线程在单核上实现的是并发多进程在多核上可以实现并行。这个区分很重要因为一个任务从“能响应”到“执行的更快”可能需要对模型做完全不同的改变。比如一个 Web 服务用协程能做到高并发响应但如果某个请求内部有大量计算即便协程再多这个请求依然慢。这时候要在协程里把计算任务丢给进程池让其他核心真正跑起来。理解并发和并行等于理解了“快”和“活”的区别。协程擅长让系统活着进程擅长让系统更快线程则夹在中间。3. 实操线程与进程的使用与细节3.1 用 threading 创建线程的完整姿势Python 标准库threading是最直观的多线程入口。基本流程是先定义一个函数然后创建Thread对象调用start()最后用join()等待线程结束。import threading import time def worker(name, delay): print(f线程 {name} 开始) time.sleep(delay) print(f线程 {name} 结束) t1 threading.Thread(targetworker, args(A, 2)) t2 threading.Thread(targetworker, args(B, 1)) t1.start() t2.start() t1.join() t2.join() print(主线程结束)需要注意几点args必须传元组所以我写(A, 2)少写逗号会变成字符串容易踩坑。join()是必需的否则主线程提前退出子线程可能被直接终止。不要通过改名run()来执行逻辑除非你自定义子类直接用target更明确。如果想让线程循环执行特定任务可以用threading.Timer做延时任务或者写个while循环加个退出事件。一种常见的模式是用threading.Event控制线程停止而不是直接调用terminate()因为 Python 线程没有强制终止的方法。3.2 线程锁与线程安全原子操作不是免费的共享变量是线程编程的经典坑。看一个例子import threading counter 0 def increment(): global counter for _ in range(100000): counter 1 threads [threading.Thread(targetincrement) for _ in range(4)] for t in threads: t.start() for t in threads: t.join() print(counter) # 期望 400000实际大概率小于这个数为什么结果不对因为counter 1不是原子操作它分成取值、加法、赋值三步。多个线程交错执行最后赋值会覆盖前面的结果。解决办法是加锁lock threading.Lock() def increment_safe(): global counter for _ in range(100000): with lock: counter 1用with lock可以确保同一时间只有一个线程执行这段代码。但锁会降低并发度所以锁的粒度越小越好。像这种只保护一个变量的场景也可以用queue.Queue或multiprocessing.Value自带的锁。线程安全的漏洞很难排查所以我的经验是能用不可变数据、能用局部变量就尽量少用共享状态。很多情况下每个线程把结果算完最后集中合并比一堆线程同时改同一个变量要稳得多。3.3 线程池 ThreadPoolExecutor 的正确使用线程池比手动创建线程更推荐因为线程创建和销毁都有成本池可以复用。concurrent.futures.ThreadPoolExecutor是现代 Python 首选。from concurrent.futures import ThreadPoolExecutor, as_completed import time def fetch(url): time.sleep(1) # 模拟网络请求 return f{url} 的结果 urls [url1, url2, url3, url4, url5] with ThreadPoolExecutor(max_workers3) as executor: futures [executor.submit(fetch, url) for url in urls] for future in as_completed(futures): print(future.result())max_workers建议不要开太大。IO 密集虽然可以多开但线程切换和内存占用会随之上升。通常我给普通爬虫任务开 5~10 个给文件读写开 4~8 个。如果单线程里的任务本身很快开太多线程反而会增加调度开销。as_completed()会按完成顺序返回结果适合处理不要求返回顺序的高并发任务。如果必须按输入顺序返回用executor.map()更方便但它会等前面的任务完成返回顺序是固定的。3.4 用 multiprocessing 实现真正的多核并行如果任务是 CPU 密集型绕开 GIL 的正解是multiprocessing。它创建的是独立进程每个进程有独立解释器和内存空间。看一个基础例子from multiprocessing import Process import os def heavy_calc(n): print(f进程 {os.getpid()} 计算 {n}) return n * n if __name__ __main__: ps [Process(targetheavy_calc, args(i,)) for i in range(4)] for p in ps: p.start() for p in ps: p.join()注意if __name__ __main__在 Windows 上多进程需要入口保护否则会递归创建子进程甚至报错。这在 Linux 上不那么严格但写进代码里是统一规范的。多进程之间不共享变量所以生产环境里最常用的通信方式不是直接改变量而是用队列multiprocessing.Queue。主进程派发任务子进程从队列取任务再把结果放回队列。模式如下from multiprocessing import Process, Queue def worker(q_in, q_out): while True: item q_in.get() if item is None: break result item * 2 q_out.put(result) if __name__ __main__: q_in Queue() q_out Queue() p Process(targetworker, args(q_in, q_out)) p.start() for i in range(5): q_in.put(i) q_in.put(None) # 向 worker 发送结束信号 p.join() while not q_out.empty(): print(q_out.get())这里None是常用的哨兵对象用来通知子进程退出。如果不加子进程会一直阻塞在q.get()上进程无法正常结束。3.5 进程池与跨进程数据共享如果任务相对独立用multiprocessing.Pool或concurrent.futures.ProcessPoolExecutor会更优雅。ProcessPoolExecutor 的 API 和线程池几乎一样改一下导入即可from concurrent.futures import ProcessPoolExecutor def square(n): return n ** 2 if __name__ __main__: with ProcessPoolExecutor(max_workers4) as ex: results ex.map(square, range(10)) print(list(results))但要注意进程池里传的参数必须能被 pickle 序列化。自定义类、lambda 函数、局部函数都可能出问题。协程、嵌套函数、某些动态生成的对象都不行。这是新手最常见的问题代码本身没错就是序列化失败。如果确实需要在进程间共享比较复杂的数据multiprocessing.Manager可以提供代理对象比如 Manager 下的 list、dict、Namespace。它是通过独立进程管理的访问速度比队列慢但是方便。对性能要求不高的配置同步、状态统计任务够用。另外进程模式在 Windows 上启动开销很大每次都重新 import 主模块。所以尽量把计算任务放在if __name__ __main__里避免不必要的模块级重复初始化。4. 实操协程与异步编程4.1 async/await 基础语法先甩掉老思想协程让很多习惯了同步思维的人不适因为代码的执行顺序不再是从上到下一字排开。什么函数能await必须是被async def声明的协程函数或者类似 Future/Task 的对象。普通函数里不能使用await。import asyncio async def say_hello(): print(hello) await asyncio.sleep(1) print(world) async def main(): task asyncio.create_task(say_hello()) await task asyncio.run(main())这里最直观的区别是asyncio.sleep(1)不是让整个线程睡 1 秒而是让出控制权事件循环可以执行其他任务。asyncio.run()是 Python 3.7 后的入口它负责创建事件循环、运行主协程、关闭事件循环。记住一条铁律协程函数只有在被调度后才会真正执行。只调用say_hello()得到的是一个协程对象不会打印任何内容。必须用await、create_task()或asyncio.run()包一层。4.2 用 gather 并发执行多个协程最常用的并发执行方式是asyncio.gather()。它接收一组可等待对象并发的执行它们然后按传入顺序返回结果。import asyncio async def fetch_data(name, delay): await asyncio.sleep(delay) return f{name} done async def main(): results await asyncio.gather( fetch_data(A, 2), fetch_data(B, 1), fetch_data(C, 3), ) print(results) asyncio.run(main())三个协程会并发执行总耗时接近 3 秒而不是 6 秒。gather在结果顺序上是稳定的但它内部是并发调度。如果其中一个任务抛异常整个gather默认会向上抛异常并取消其他任务。如果希望一个任务挂了不影响其他任务可以传入return_exceptionsTrue这样异常会作为结果返回而不是直接中断。除了gatherasyncio.wait和asyncio.as_completed也常用。gather适合聚合结果as_completed适合按完成顺序处理流式任务。我在写多 URL 请求时经常把as_completed配create_task用类似线程池里的as_completed。4.3 在协程中正确执行阻塞操作这是协程编程最容易翻车的地方。如果在协程里写了time.sleep(1)事件循环会被卡住整整 1 秒哪怕还有其他 IO 任务等着。因为time.sleep是同步阻塞函数不会让出控制权。同样的道理适用于requests.get()、open().read()这类同步 IO。正确做法是使用asyncio.to_thread或把阻塞操作放到线程池。import asyncio import time def blocking_read(): time.sleep(2) return data async def main(): data await asyncio.to_thread(blocking_read) print(data) asyncio.run(main())asyncio.to_thread是 Python 3.9 后的好帮手会把阻塞函数放到线程池里执行同时让协程暂停事件循环继续服务其他任务。但要注意如果创建大量to_thread底层还是一个线程池不要以为协程就真的“无极限”了。传统方式是用loop.run_in_executor。在 Python 3.10更推荐asyncio.to_thread这种简洁语法。还有一个选择是直接把同步库换成异步库比如用aiohttp代替requests用aiofiles代替普通文件读。能异步化就异步化性能最好。4.4 协程性能对比到底能省多少很多读者关心协程比线程快多少。实际测试中普通网络请求场景下协程和线程差距不算巨大但协程在“高并发海量连接”场景优势明显。我的经验是当并发量超过几百甚至上千以后线程会因为栈空间和调度开销变得笨重而协程依然游刃有余。每个协程占用内存远远小于线程线程栈默认数百万字节协程栈可能只要几 KB。不过协程并不是万能的它最大的劣势是“传染性”。你用了async def就希望整个调用链都是异步的。项目里如果有老的同步库、第三方 SDK混写会非常别扭。这时候我会谨慎评估是把整个模块重写成异步还是用线程池把同步调用隔离出去。这两种思路都可行但不要一边用async一边到处to_thread否则架构会很混乱。5. 常见问题与排查技巧实录5.1 线程竞争与数据不一致加锁之外还有招线程竞争是我在代码 review 时最常看到的问题。除了维护复杂的锁逻辑一个更简单的思路是让任务彻底无共享。比如把每个线程要处理的数据都做成独立副本线程只操作自己的数据最后用futures.result()或者队列汇总。这样根本不需要锁出错概率大大降低。如果确实需要共享计数器、缓存等尽量用线程安全的容器比如queue.Queue、collections.deque某些操作是原子的、threading.local线程局部变量。threading.local()很值得推荐它可以为每个线程维护独立数据模拟“全局变量但互相隔离”的效果。排查线程问题时先看现象是不是偶发、是否和并发数相关。如果结果随机变基本就是数据竞争。可以先在代码里加上threading.current_thread().name打印每个线程的状态再逐步缩小范围。5.2 进程之间数据传递序列化陷阱多进程最常见的坑是pickle序列化问题。ProcessPoolExecutor的map或submit在提交任务时会把函数和参数序列化后再发给子进程。如果函数是闭包、lambda、带yield的生成器、或者引用了不可序列化对象就会直接报错。解决思路有三种把任务函数定义在模块顶层并且只传基础类型参数。用multiprocessing.Manager提供跨进程容器但性能会下降。实在绕不开繁重共享数据考虑直接改用第三方方案比如把任务数据通过pickle文件或数据库暂存。还有一个容易忽略的问题子进程里的print不一定按顺序出现在终端因为输出流是分开缓冲的。调试时要加flushTrue或者把日志写到文件否则很难看执行路径。5.3 协程卡死、不退出、结果不返回协程程序常见的卡死场景是某个协程迟迟没有await导致事件循环无法执行或者await的是一个永远不会有结果的 Future。排查时先看所有await是否都发生在非阻塞调用上再看任务里有没有死循环。另一个常见问题是“忘了调用asyncio.run或get_event_loop”导致协程对象被创建但从未执行。新手容易把async def main()里的 main 当作普通函数调用控制台只显示RuntimeWarning: coroutine was never awaited。遇到这个警告第一反应就是在前面加asyncio.run()。异步资源也需要手动清理。打开多个网络连接时最好用async with管理会话比如aiohttp.ClientSession。否则事件循环关闭时可能残留连接影响程序退出。在main结束前显式await掉所有 task是更稳妥的习惯。5.4 死锁与排查工具速查死锁多发生在线程或进程之间互相等待锁。比如 A 线程持有锁 1等待锁 2B 线程持有锁 2等待锁 1。这种问题很难用肉眼看出来最好直接上工具。Python 3.10 之后可以通过faulthandler.dump_traceback_later(10)在程序运行 10 秒后自动输出线程栈快速定位卡住的位置。faulthandler是标准库实用性强。另外pysnooper这类调试库也可以打日志生产环境慎用性能开销大。排查步骤我通常这么走用logging记录每个关键锁的 acquire 与 release。观察锁等待时间超过阈值的记录。检查获取多个锁的顺序是否一致。如果有两个线程按相反顺序申请锁就极容易死锁。统一锁顺序、减少锁粒度、用超时锁lock.acquire(timeout3)兜底。5.5 一张速查表进程线程协程怎么选最后附一张我在方案评审时经常用的速查表方便快速定位场景推荐方案理由大量网络请求、长连接协程async aiohttp高并发占用小爬虫抓取几十个 URL线程池ThreadPoolExecutor简单够用兼容同步库图片批量处理、数据计算进程池ProcessPoolExecutor利用多核 CPUCPU 密集 IO 密集混合协程 进程池组合各干各擅长的复杂业务共享全局状态尽量避免必要时加锁共享越少问题越少我个人的习惯是先把“纯 CPU”和“纯 IO”分开然后各自选模型最后再用队列或 Future 把它们串起来。这种方式写出来的代码结构清晰排查问题也方便。多任务编程真正难的不是 API而是思维方式接受并发、接受不确定性、接受调度。很多东西只有自己跑一遍看到计数器错乱、死锁或卡住的瞬间才算真正理解。如果你的项目还停留在单线程我建议从线程池开始改再逐步引入协程。步子大容易折循序渐进最稳。最后再分享一个小技巧无论是写threading、multiprocessing还是asyncio都要想清楚“谁负责等待”和“谁负责退出”。只要把每个任务的进入条件、结束信号、异常处理都写明确并发代码就成功了大半。多任务不是魔法是用规则管理复杂性规则越简单系统越稳。
