很多人学Python学到并发这块都会碰到一个绕不开的坎明明开了多线程程序反而更慢了CPU占用也没上去。于是网上就开始流行“Python多线程没用要性能就用多进程”的说法。这句话只对了一半但能把背后的全局解释器锁GIL原理讲清楚的人确实不多。这篇文章想从GIL讲起把多线程和多进程的适用边界彻底拆开给你一套能直接落地的选型思路和代码方案。这篇文章适合谁看一是刚学完Python基础、准备进入并发编程的开发者二是写过一些爬虫或者接口脚本、但分不清该用线程还是进程的人三是准备面试、需要把并发这块讲明白的同学。读完你至少能回答三个问题GIL到底是什么为什么多线程在CPU密集型任务上不给力遇到实际问题时到底该选线程、进程还是协程。1. 先搞清楚GIL到底锁住了什么1.1 GIL是历史包袱也是现实约束GIL的全称是Global Interpreter Lock全局解释器锁。它是CPython解释器也就是官方Python解释器里的一个互斥锁作用是在同一时刻只允许一个线程执行Python字节码。说白了不管你开8个线程还是16个线程在同一个进程内任何时刻只有一个线程能真正执行Python代码。其他线程要么在等待锁要么在释放GIL后才能拿到执行权。这个设计不是拍脑袋来的。Python 2时代解释器的内存管理机制引用计数本身就不是线程安全的。如果没有这把全局锁多个线程同时操作对象的引用计数内存会被改得乱七八糟程序会频繁崩溃。当时为了保住解释器的稳定性和开发效率官方选择了“用一把大锁牺牲多核并行能力”这条路。所以要注意GIL锁的对象是“执行Python字节码”这个动作不是锁住整个进程的I/O操作也不是锁住所有的C扩展库调用。这个区分极其重要后面所有选型判断都基于它。1.2 线程切换的真正开销在哪既然同一时刻只有一个线程跑Python代码那么多线程还有什么意义答案在于当线程遇到阻塞操作时会主动释放GIL。比如网络请求等待响应、文件读写等待磁盘、数据库查询等待返回这些操作发生时线程不需要CPU资源这时候GIL可以被其他线程拿过去执行。Python内部有个机制叫“线程切换间隔”thread switching interval默认是5毫秒。也就是说一个线程连续执行5毫秒后即使没有遇到阻塞操作也会强制释放GIL让其他线程获得执行机会。这就保证了多个线程在宏观上都能跑一跑不至于饿死某一个。但这里就出现了一个关键问题线程切换是有代价的。每次切换GIL都要经历加锁、释放锁、上下文切换的过程尤其当线程数量很多、任务切换频繁时这部分开销会非常可观。这就是为什么有些场景下多线程甚至比单线程还慢。1.3 不同类型任务的GIL表现差异我们用两类典型任务来感受一下差异CPU密集型任务任务是纯计算比如数值积分、图像像素处理、复杂算法循环。这类任务全程需要CPU线程没有阻塞于是GIL成为绝对的瓶颈。开多线程本质上还是轮流执行不仅没提升还多付出切换开销性能甚至下降。I/O密集型任务任务是网络请求、文件读写、数据库操作。这类任务有大量时间在等待外部设备线程在等待时会释放GIL其他线程得以执行各自的I/O操作。多线程能明显提升整体的吞吐量效果立竿见影。这个二分法是选型的核心依据后面所有策略都从这里出发。2. 多线程与多进程的本质差异2.1 资源模型共享内存vs独立进程先看操作系统层面的差异。线程是进程内的执行单元同一个进程里的所有线程共享内存空间。这意味着线程之间可以很方便地访问同一个变量、同一个对象。但方便的同时也带来了麻烦必须用锁Lock、条件变量Condition等机制来保护共享数据否则会出现数据错乱。进程是独立运行的程序实例每个进程有自己独立的内存空间。进程之间不共享变量通信需要借助专门的机制比如队列Queue、管道Pipe、共享内存等。好处是隔离性好一个进程崩了不影响其他进程坏处是通信成本高每次传递数据都要做序列化和反序列化。用生活类比的话线程像同一个办公室里共享一块白板的同事沟通直接但白板上的字容易被别人擦掉或覆盖需要立规矩进程像不同办公室的人各写各的笔记互相不打扰但需要跨办公室送文件传递效率低一些。2.2 并发与并行一字之差效果完全不同并发Concurrency是指多个任务在宏观上看起来是同时执行的微观上可能是交替执行。并行Parallelism是指多个任务在物理上同时执行真正利用多核CPU。由于GIL的存在CPython的多线程只能实现“并发”无法实现“并行”。多进程不一样每个进程有独立的解释器和独立的GIL所以多个进程可以真正“并行”各自跑在不同的CPU核心上。举个例子一台4核机器上跑一个任务涉及大量计算。开4个进程可以4个核同时工作理论上加速比接近4倍开4个线程只有一个核在工作另外三个核在看热闹理论上加速比约等于1。2.3 两大方案的核心对比对比项多线程多进程受GIL影响是无法并行执行Python代码否每个进程独立GIL适合任务类型I/O密集型CPU密集型数据共享共享内存读写方便但需加锁独立内存需通过队列/管道通信通信成本低直接访问对象高需序列化传输启动开销低线程创建快高进程创建慢隔离性差线程崩溃影响进程好进程间互不影响调试复杂度中需处理竞态条件高需处理IPC和状态同步这个表格是我在实际项目中反复验证过的。你要选型时先对着这张表过一遍方向基本不会错。3. 选型判断什么场景用什么方案3.1 铁律先分清你是CPU密集还是I/O密集我在带团队做技术方案评审时最常问的一句话就是你的任务到底是在等CPU还是等网络/磁盘如果是等CPU也就是说任务的计算逻辑很重比如图像处理、视频编码、大规模数值计算、循环里做复杂数学运算那么优先考虑多进程或者直接把核心计算部分用numpy、C扩展等方案替代因为这些库底层会释放GIL能实现真正的并行。如果是等I/O比如爬虫抓网页、调用第三方API、读写数据库、批量文件处理那么优先考虑多线程甚至协程。这类任务开多线程能把等待时间利用起来吞吐量提升非常明显。还有一个容易忽略的点如果你的任务本身很轻比如只是循环做一些简单操作那么不管选择多线程还是多进程性能都不一定比单线程好。并发是有开销的任务太轻时并发开销反而淹没了收益。遇到这种情况先写好单线程版本用profile工具测一测瓶颈在哪里再做决定。3.2 I/O密集场景下线程池是首选我自己的经验是I/O密集场景直接用concurrent.futures.ThreadPoolExecutor不要手动管理线程。手动创建线程看起来很灵活但线程池能帮你处理线程复用、任务队列、结果收集这些脏活累活。这里给一个典型的参考代码批量抓取网页的场景import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed URLS [ https://httpbin.org/delay/1, https://httpbin.org/delay/2, https://httpbin.org/delay/1, https://httpbin.org/delay/3, https://httpbin.org/delay/1, ] def fetch(url): resp requests.get(url, timeout5) return url, resp.status_code start time.perf_counter() with ThreadPoolExecutor(max_workers5) as executor: futures {executor.submit(fetch, url): url for url in URLS} for future in as_completed(futures): url futures[future] try: status future.result() except Exception as exc: print(f{url} 请求失败: {exc}) else: print(f{url} 返回状态码 {status[1]}) print(f总耗时: {time.perf_counter() - start:.2f}秒)这段代码里5个请求分别延迟1、2、1、3、1秒如果串行执行总耗时会超过8秒用5个线程并发执行总耗时约等于最慢的那个请求也就是3秒左右。这就是I/O密集场景下多线程的价值。这里有一个关键点as_completed是按完成顺序返回结果的不是按提交顺序。如果你希望结果按提交顺序保存可以用一个字典先把future和下标绑定完成后填入结果列表。我经常看到有人用executor.map如果其中一个任务抛异常整个map迭代器会中断这在生产代码里是个隐患。3.3 CPU密集场景下进程池的用法要稳CPU密集任务用concurrent.futures.ProcessPoolExecutor或者multiprocessing.Pool都可以。我推荐前者接口更友好而且配合as_completed用起来非常顺手。一个典型的CPU计算例子计算一堆数字的立方和import time from concurrent.futures import ProcessPoolExecutor def heavy_compute(n): total 0 for i in range(n): total i * i * i return total if __name__ __main__: numbers [3000000, 3000000, 3000000, 3000000] start time.perf_counter() with ProcessPoolExecutor(max_workers4) as executor: results list(executor.map(heavy_compute, numbers)) print(进程池计算结果:, results) print(f总耗时: {time.perf_counter() - start:.2f}秒)在4核机器上这段代码4个进程并行总耗时接近单进程运行一个任务的耗时而不是4个任务串行的耗时。如果是ThreadPoolExecutor跑同样的任务因为GIL的存在总耗时反而会比单进程直接跑还略慢因为线程切换白白消耗了时间。注意进程池的任务函数必须能被pickle序列化。这意味着你不能直接提交一个lambda匿名函数也不能提交定义在函数内部的嵌套函数。我踩过这个坑第一次用ProcessPoolExecutor提交lambda直接报AttributeError花了不少时间才定位到问题。解决办法是把任务函数定义在模块顶层确保它是全局可导入的。3.4 混合型任务分成两个阶段处理实际业务里更多是混合型任务比如先批量下载数据再做全局计算。这时候不要试图用纯线程或纯进程解决所有问题而是把任务拆成两个阶段I/O阶段用线程并发计算阶段用进程并行。我的习惯做法是把两个阶段串起来中间用队列传递数据。I/O线程把数据写入queue.Queue进程池的工作函数从队列里读取但这里要特别注意multiprocessing的进程池不能直接消费线程里的queue.Queue因为不同进程内存不共享。正确做法是用multiprocessing.Queue或者把I/O结果先落盘/入库计算阶段再重新读取。还有一种更轻量的选择如果I/O阶段的并发量需要很大比如几千个请求线程本身的管理开销可能太大这时候可以考虑协程。用asyncio配合aiohttp单线程就能处理几千个并发连接效果远好于多线程。协程是另一种并发模型不受GIL影响因为它是单线程内的事件循环调度遇到I/O自动挂起让出执行权。4. 实操一套可落地的并发方案4.1 结合GIL特性优化代码理解了GIL的切换机制后写代码时可以有两个实用优化思路。第一个思路是尽量避免在持锁期间做重量级操作。比如多线程共享数据需要加锁锁里面的代码要尽量短小只保护真正需要保护的临界区。不要在锁里面写文件、发网络请求这会放大锁的持有时间拖累所有线程。第二个思路是让C扩展库释放GIL来加速计算。numpy、pandas这类科学计算库底层很多操作是用C语言实现的它们会在计算时主动释放GIL因此多线程调用numpy反而能获得接近并行的效果。我们做一个多线程并行操作numpy数组的任务性能会比纯Python循环好一个数量级。这里给一个简单的对比思路参考做一个百万次纯Python累加操作单线程耗时约0.08秒开2个线程耗时约0.09秒其实不升反降但用numpy的向量化加法同样规模的操作耗时约0.001秒量级远快于纯Python。数据层面的优化往往比并发模型的选择更重要先优化单核效率再考虑并发。4.2 明确选择ThreadPoolExecutor还是ProcessPoolExecutorconcurrent.futures里的两个执行器用法基本一样但底层差异很大我列一下我的选择标准任务是I/O密集或者任务函数内部调用了numpy这类能释放GIL的库用ThreadPoolExecutor。任务是纯Python计算且计算量很大用ProcessPoolExecutor。任务需要频繁传递大量数据进程间的序列化开销会拖慢整体速度尽量设计成数据传递少、初始参数一次性传入的模式避免每轮都传大数据。任务对延迟敏感比如需要快速响应进程创建的开销可能无法接受。这种情况可以考虑初始化时就创建好进程池常驻进程而不是临时起进程。还有一点ProcessPoolExecutor在Windows平台上使用有额外的限制任务函数必须写在if __name__ __main__:保护的代码块里否则会因为递归导入问题报错。Linux和macOS没有这个限制但为了跨平台兼容我一般都会写上这个保护形成习惯避免换平台后踩坑。4.3 并发量级的选择策略很多新手最关心的一个问题是线程数或进程数到底开多少合适对于I/O密集任务理论上线程数可以比CPU核心数多很多。常见的经验值是min(32, os.cpu_count() 4)这个值来自Python官方文档的建议适合大多数网络请求场景。但如果你请求的第三方服务有并发限制比如只允许同时10个连接那么开32个线程也没意义反而被对方限流。这时候应该以服务端的限制为准提前测一下接口的并发上限。对于CPU密集任务进程数一般不要超过CPU物理核心数。如果你的机器是4核8线程的超线程设置max_workers8有时能获得一定提升但不一定线性。最稳妥的办法是用os.cpu_count()获取逻辑核心数然后通过实测调整。我自己的实测经验是CPU密集任务开进程数超过物理核心数后性能提升极其有限还会因为进程切换和内存竞争而下降。你可以跑一个简单的基准测试固定任务量不变依次把worker数量设为1、2、4、8绘制耗时曲线找到拐点就是最优值。这也是面试时能说出“为什么不能盲目增加worker”的底气。4.4 线程与进程的选择决策树为了让你在真实项目中快速做判断我整理了一个简化版决策树推荐先问任务主要是等CPU还是等I/O等I/O再问并发量是不是很大比如上千个连接如果很大优先考虑协程如果中等规模用ThreadPoolExecutor。等CPU再问计算逻辑是纯Python还是依赖numpy等C库如果是纯Python用ProcessPoolExecutor如果能用numpy向量化先优化计算本身必要时再进程并行。两种任务混合按阶段拆分I/O阶段和计算阶段分别用不同的并发模型。这套决策树不是万能的但覆盖了90%以上普通项目的需求。真正的极端场景比如海量并发或超大规模分布式计算需要引入更专业的方案比如消息队列、分布式任务框架那就超出本文范畴了但选型逻辑依然一样。5. 实战中的常见问题与排查技巧5.1 为什么多线程在计算任务中反而更慢这是最高频的困惑。你已经知道原因是GIL了但具体慢在哪里可以自己验证一下。写一段纯Python计算分别用单线程、2线程、4线程跑并记录耗时。我的经验结果是2线程和单线程耗时几乎一样4线程反而更慢。原因很容易理解任务本身没有阻塞线程切换成了纯开销。每5毫秒强制切换一次线程越多切换越频繁缓存命中率越低性能就越差。遇到这种情况排查思路不是去看代码逻辑而是先确认任务的CPU占比。用cProfile对单线程版本做性能分析如果大部分时间花在纯Python层级的循环和计算上那就必须考虑用进程或者把热点代码改成C扩展。5.2 共享全局变量居然没生效多线程共享全局变量但要小心Python的GIL并不会保证你的代码安全。一个经典面试题两个线程同时对同一个整数执行100万次加1操作最终的结果一定小于200万。原因在于count 1不是原子操作它分成了读、加、写三步。两个线程可能同时读到同一个值加完写回导致其中一次操作被覆盖。虽然GIL会让线程在字节码间隙切换但三步操作之间也可能发生切换所以结果会出错。解决方案也很简单就是给操作加锁import threading lock threading.Lock() counter 0 def increment(): global counter for _ in range(1000000): with lock: counter 1 threads [threading.Thread(targetincrement) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() print(counter) # 正确结果是 2000000千万不要以为因为有了GIL所有多线程代码都是安全的。GIL只保护解释器内部的内存管理不保护你的业务逻辑。5.3 多进程通信最容易踩的坑进程间通信最常见的方式是用multiprocessing.Queue。但有个细节很多人不知道当你往队列里放数据时数据会被序列化pickle后写入一个底层管道这个操作本身是有开销的。如果传输的数据很大比如一个大DataFrame或大列表通信时间可能比计算时间还长进程并行的优势就被抵消了。我测试过一个具体案例进程池跑一个简单计算任务如果每个任务附带一个10MB的字符串参数20个任务的传输时间可能比计算时间长好几倍。优化办法有两种一是把大数据先写成临时文件传递文件路径让子进程自己读文件二是改用共享内存机制比如multiprocessing.shared_memory库但要处理更复杂的内存管理逻辑业务复杂时不推荐新手直接上手。5.4 程序假死或卡住怎么排查这是并发程序最让人头疼的问题。常见原因有死锁多个线程持有了互相等待的锁。排查方法是在代码中给每个锁命名配合threading的锁排序规范让所有线程按固定顺序获取锁还可以用faulthandler模块打印程序卡住时的堆栈直接定位卡在哪一行。任务排队堆积线程池满了新任务一直在等待看起来像假死。排查方法是在提交任务前先检查线程池的剩余容量或者改用有界队列并设置超时。子进程异常退出ProcessPoolExecutor里某个任务崩了主进程可能一直等待结果。排查方法是先缩小数据量复现打开multiprocessing的日志看看是否报错。我自己的习惯是在并发代码的入口和关键节点打日志记录任务开始、结束、异常信息。先跑一个小规模的数据集验证正确性再放大到全量数据这样可以快速区分是逻辑错误还是并发问题。5.5 一个通用的并发性能测试模板选型时不要靠感觉最好跑一个简单的基准测试。模板思路如下准备一个任务分别串行跑一段固定时间作为对照基线。用线程池跑同一任务记录耗时。用进程池跑同一任务记录耗时。对比三组数据结合资源占用CPU、内存做最终决定。我遇到过一个真实的选型案例一个图像处理脚本原先用ThreadPoolExecutor处理一张张图片耗时20秒改成ProcessPoolExecutor后耗时降到6秒提升明显。但另一个场景是批量下载文件ThreadPoolExecutor比ProcessPoolExecutor快得多而且内存占用更少。同一台机器、同一个项目只是任务类型不同最优方案完全相反。这就是为什么一定要先测再选。6. 面试里高频出现的GIL细节6.1 GIL到底能不能去掉这是一个很经典的面试题。从Python 3.9开始官方在PEP 554里讨论了子解释器方案后来又有一些多线程自由线程化的实验性尝试。但到目前为止标准CPython依然保留GIL。原因很现实去掉GIL需要解决大量的内存模型问题兼容海量的C扩展库工程成本极高而且双版本维护代价巨大。短期内你写普通的Python业务代码时GIL会一直存在。与其纠结GIL能不能移除不如理解清楚它的边界Python的GIL只约束Python字节码的执行不约束操作系统层面的I/O也不约束释放了GIL的C扩展。这个理解在面试和实际工程里都够用了。6.2 进程池和线程池的异常处理差异线程池里的future.result()能拿到异常对象可以直接打印堆栈。进程池里的future.result()也会把子进程的异常传回主进程但注意如果子进程是通过os._exit()之类的方式强制退出主进程拿不到任何异常信息而是BrokenProcessPool。这种情况下需要先检查子进程是否真的正常运行完毕而不是盲目扩大重试次数。6.3 什么时候该用协程最后补一个高频比较题协程 vs 线程 vs 进程。协程是单线程内的用户态调度没有线程切换的系统开销创建成本极低能轻松支撑上万个并发任务。但它要求任务本身是异步友好的也就是说代码里不能有阻塞的同步I/O调用否则会阻塞整个事件循环。它的最佳场景是大规模I/O密集型任务比如高并发的网络服务、爬虫、实时数据处理管道。如果你只需要几百个并发连接用线程就够了没必要上协程因为异步改造本身也有学习成本和代码复杂度。写在最后我个人在实际项目里摸索出来的体会是并发方案的选择先看任务类型再看数据规模最后才看代码实现。很多新手一上来就写线程池、进程池却没想过这个任务到底需不需要并发。先把单线程版本跑通用性能分析工具找瓶颈再决定用哪种并发模型这样最稳。另外想分享一个小技巧在判断进程中通信是否成了性能瓶颈时可以对比两个时间一是总耗时二是纯计算耗时。如果总耗时比纯计算耗时多出一大截那么多半是通信开销太大。这时候不要急着换并发模型先优化数据的传递方式比如压缩数据、减少传递频次或者改用共享内存往往比盲目加进程数更有效。Python的并发世界肯定不完美GIL被吐槽了二十年但理解了它之后反而能在合理的地方发挥出多线程的优势。下次再写并发代码时先问自己一句我的任务是在等CPU还是在等网卡和磁盘答案出来方案基本就定了。