Python的多线程就是个假把式。我第一次听到这句话是在一个周五晚上的加班现场。那时候我正蹲在工位上对着一台CPU占用率死活上不去的机器发呆。代码跑的是多线程批量任务数据量不大耗时却比单线程还久任务进度条卡在一个位置不动眼看着周六早上就要上线。带着满肚子怀疑我把Python并发机制从头翻了一遍才真正搞清楚GILGlobal Interpreter Lock全局解释器锁是怎么回事。这篇文章就是我连续熬了三天、踩了无数坑之后沉淀出来的结果想给所有写过Python多线程却觉得怎么没效果的朋友讲透GIL的底层逻辑也顺便给出我实测后一直在用的方案。无论你是写爬虫、做数据批处理还是处理高并发接口只要你在Python里碰过线程这篇文章都值得花十分钟看完。GIL这东西说简单也简单说复杂也复杂。简单到一句话就能概括CPython解释器同一时刻只允许一个线程执行Python字节码。复杂到它牵扯了内存管理、线程调度、C扩展、历史设计取舍任何一个地方都可能成为性能瓶颈的源头。网上聊GIL的帖子不少但大多只讲现象不讲原因更不给实操方案。我这篇会把整个来龙去脉拆开讲从原理到实测再到避坑一篇给你讲清楚。1. GIL到底锁了什么一个被误读的全局锁1.1 为什么Python多线程会被说成假把式在解释GIL之前先看一个几乎所有Python开发者都会遇到的现象。你写一个很纯粹的计算函数比如反复做数学运算然后开4个线程去跑相同任务结果总耗时和单线程跑4次几乎一样甚至还有可能更慢。你换成进程试试速度瞬间提上去。这个现象太反常了因为其他语言里多线程就是用来做并行计算的怎么到了Python这里就失效了于是Python的多线程是假把式这句话就在开发者群里流传开了。要理解这句话得先明白Python线程本身的属性。在CPython里threading模块创建的每个Thread底层都是真实的操作系统线程由操作系统负责调度。也就是说线程是真的并没有被做成伪线程。那么假在哪里假在它们无法同时执行Python代码。无论你创建多少个线程同一时刻只能有一个线程进入解释器执行字节码其他线程哪怕已经具备运行条件也只能在门外排队等待。这就造成了一种尴尬局面多线程的壳子装的是单线程的内核CPU密集任务不但没有加速反而多了调度开销。1.2 GIL的诞生与其合理性历史选择下的设计取舍为什么CPython要设计这样一个看起来毫无并发诚意的锁这得从Python的内存管理说起。CPython在管理对象生命周期时使用引用计数来追踪每个对象的存活状态。每当你创建一个新引用指向某个对象它的引用计数会1引用被销毁时-1当计数归零时解释器马上回收这块内存。问题来了如果有两个线程同时修改同一个对象的引用计数就可能出现计数错乱。比如一个线程正在将该对象计数从1减到0并回收内存另一个线程同时尝试增加引用计数这时这个对象实际已经不存在了程序轻则数据损坏重则直接崩溃。解决办法有很多最容易想到的是给每个对象都加一把细粒度锁但对象数量动辄百万千万锁内存开销和加锁开销都不小会让解释器整体性能大打折扣。于是CPython选择了一个简单粗暴却极其有效的思路在解释器级别加一把全局锁同一时刻只让一个线程跑Python字节码引用计数的问题从根本上就不存在了。从设计者的角度看这个方案在当时是相当务实的。Python本身并不是为了高性能并发而生的语言它的核心优势是开发效率。在GIL的保护下内存管理变得简单且稳定大量C扩展库可以省掉内部同步的功夫直接享受解释器提供的隐式线程安全。那个年代多核CPU还没有普及单线程性能对多数场景来说够用GIL带来的影响也就没有今天这么突出。1.3 为什么至今没移除GIL一个更现实的答案很多人可能会问既然GIL导致多线程无法真正并行Python官方为什么不把它干掉这个问题我当年也困惑了很久了解得越深越发现移除GIL远比想象中复杂。首先是技术工程量的原因。去掉GIL意味着CPython整个内存管理模型要推倒重来引用计数、垃圾回收、对象分配都必须引入细粒度锁来保证线程安全这项工作是十年甚至更长时间级别的不是改几行代码就能完成的。其次是单线程性能的代价。为了追求多线程并行而给所有数据结构都加锁很可能会让普通单线程程序的执行效率明显变慢而绝大多数Python脚本本来就是单线程的。用大多数用户的性能损失去换取少数并发场景的收益这个账并不划算。第三个原因是C扩展生态的兼容性。大量第三方库用C编写依赖GIL提供的保护比如numpy、pandas、opencv这些库在底层都大量运行计算密集型C代码。如果GIL消失这些库必须重新设计和验证线程安全问题工作量极大。PEP 703一直在探索无GIL的方向但距离在生产环境默认启用还有非常长的路。1.4 一个关键补充GIL不是啥都锁在深入GIL的时候很多人会陷入另一个误区认为GIL锁住了整个进程导致所有操作都无法并发。实际上GIL只锁Python字节码的执行而且锁的持有是有条件的。一旦线程进入阻塞等待状态比如等待网络数据返回、等待文件读写完成、调用了一些耗时较长且明确释放锁的C扩展接口解释器就会主动释放GIL让其他线程有机会运行。换句话说如果程序大部分时间都在等GIL并不会成为瓶颈多线程依然能获得可观的并发收益。这个特性是后面区分CPU密集与I/O密集任务的关键也是很多教程没讲透的地方。2. 分清任务类型CPU密集和I/O密集的岔路口2.1 先摆出来一条结论扯了这么多原理落到实操层面其实就一句话CPU密集型任务别用多线程直接用多进程I/O密集型任务多线程完全够用再配合asyncio性价比极高。判断你的任务属于哪一类是一切并发优化工作的起点。判断方法也很简单程序大多数时间在占用CPU做计算还是大多数时间在等待外部系统响应前者是CPU密集后者是I/O密集。比如循环一百万次求和、图像像素级处理、模型预测属于CPU密集批量网络请求、大量文件读写、频繁查询数据库属于I/O密集。2.2 I/O密集任务为什么能沾到多线程的光I/O密集的核心特征就是等待。程序发出一个网络请求后需要等待对方服务器返回数据这个等待过程普遍在几十毫秒到几秒之间线程在这种情况下处于阻塞态不消耗CPU。CPython对阻塞的处理非常聪明线程一旦进入阻塞等待GIL就会被释放别的线程立刻可以抢占执行权。也就是说虽然只有一个线程在跑字节码但等待的时间是可以互相重叠的。打个比方解释。单线程执行10个请求相当于你一个人去10个窗口排队办事每个窗口耗1秒总共10秒。多线程执行同样10个请求相当于找了10个朋友各排一个窗口大家同时等1秒多就能全部办完。因为大家在等待时都不占CPUGIL轮不轮得到根本不重要。这也是爬虫、接口调用这类场景用ThreadPoolExecutor能获得近乎线性加速的原因。我实测过用10个线程并发请求一个响应时间约0.5秒的接口总耗时从单线程的5秒压缩到0.8秒左右效果非常明显。2.3 CPU密集任务为什么越跑越慢CPU密集任务的性质完全不同整个执行过程中线程都在不断计算几乎没有主动阻塞等待的机会。此时GIL会被强制周期性地在线程之间切换保留现场、恢复现场、反复争夺锁的持有权每切换一次都要消耗时间和内存资源。从Python 3.2开始默认的切换间隔是5毫秒可以用sys.getswitchinterval()查看也就是说一个线程最多连续执行5毫秒就会被强制让出GIL下一个线程再执行5毫秒周而复始。多线程跑CPU密集任务从宏观视角看几个线程确实都在跑但微观上它们是在轮流使用同一个CPU核心的计算权而不是在多核上同时计算。除了刚刚提到的切换开销GIL竞争本身还会让线程频繁进入睡眠与唤醒状态系统调度开销全部变成额外成本。实测中4个线程跑同样的计算任务耗时不仅没有降低有时候比单线程跑4次还慢20%到40%。线程数量越多切换越频繁性能反而越差这就是假把式的真相。3. 实测现场还原三份代码看清GIL的脾气3.1 准备一个干净的测试环境光讲理论说服力不够我来还原一下当时实测的场景。测试机配置是8核CPU、16GB内存系统分别跑过Windows 10和Ubuntu 20.04Python版本是3.10结论在两个平台上基本一致。测试前建议关闭其他占用资源的程序每个用例跑5次取中位数避免偶发波动干扰判断。为了公平对比我设计了三个方向单线程、多线程、多进程分别针对CPU密集场景和I/O密集场景做计时。3.2 CPU密集对比threading vs multiprocessing vs 单线程基础测试代码如下一个累加平方数的纯计算函数cpu_task然后分别用单线程、多线程和多进程执行4次计时看结果。import time import threading from multiprocessing import Pool def cpu_task(n): total 0 for i in range(n): total i * i return total def run_single(rounds, n): start time.perf_counter() for _ in range(rounds): cpu_task(n) return time.perf_counter() - start def run_threads(rounds, n): threads [] start time.perf_counter() for _ in range(rounds): t threading.Thread(targetcpu_task, args(n,)) threads.append(t) t.start() for t in threads: t.join() return time.perf_counter() - start def run_processes(rounds, n): start time.perf_counter() with Pool(processesrounds) as pool: results [pool.apply_async(cpu_task, args(n,)) for _ in range(rounds)] for res in results: res.get() return time.perf_counter() - start if __name__ __main__: N 8_000_000 ROUNDS 4 print(f单线程耗时: {run_single(ROUNDS, N):.4f}s) print(f多线程耗时: {run_threads(ROUNDS, N):.4f}s) print(f多进程耗时: {run_processes(ROUNDS, N):.4f}s)我机器上跑出的典型结果是单线程约0.85秒多线程约1.02秒多进程约0.26秒。单线程反倒比多线程更快这还只是4个线程调度的开销。如果线程数增加到8个多线程的耗时还会继续上涨。而多进程充分利用4个CPU核心并行计算耗时接近单线程的四分之一加速比非常接近理论值。这一组数据足以说明CPU密集场景里GIL就是绕不过去的墙。3.3 I/O密集对比单线程 vs 线程池I/O密集的测试我用time.sleep来模拟网络请求等待原因很简单真实网络请求的响应时间波动太大不利于做可复现的结果对比。程序让每个任务睡眠1秒表示等待外部系统返回然后分别用单线程串行执行4次以及用4个线程并发执行4次统计总耗时。import time import threading from concurrent.futures import ThreadPoolExecutor def io_task(sec1): time.sleep(sec) return sec def run_single_io(rounds): start time.perf_counter() for _ in range(rounds): io_task() return time.perf_counter() - start def run_thread_pool_io(rounds): start time.perf_counter() with ThreadPoolExecutor(max_workersrounds) as executor: list(executor.map(io_task, [1] * rounds)) return time.perf_counter() - start if __name__ __main__: rounds 4 print(f单线程I/O耗时: {run_single_io(rounds):.4f}s) print(f线程池I/O耗时: {run_thread_pool_io(rounds):.4f}s)结果非常直观单线程耗时约4秒线程池耗时约1秒。也就是说在阻塞等待场景下4个线程几乎完美并行GIL几乎没有拖后腿。原理就是前面讲的线程阻塞时会释放GIL其他线程可以在等待期间交替运行。这也说明了为什么写爬虫时多线程仍然是一个极其有效的方案。4. 绕开GIL的实用方案多进程、线程池与协程4.1 ProcessPoolExecutor 的正确打开方式实际项目里直接用multiprocessing.Pool管理进程还是太原始了我更喜欢concurrent.futures里封装好的ProcessPoolExecutor接口和线程池几乎一致切换成本很低。from concurrent.futures import ProcessPoolExecutor def process_batch(items): with ProcessPoolExecutor(max_workers4) as executor: results list(executor.map(cpu_task, items)) return results使用时有三个实操细节需要注意。一是进程数不要盲目等于CPU核数如果机器上还有其他服务在跑建议留一两个核心给系统否则整体响应反而变慢。二是传给子进程的数据要尽量小涉及大数据集时优先考虑用共享内存或文件缓存而不是反复pickle序列化传输序列化开销一旦超过计算的收益多进程就得不偿失。三是粒度控制每个任务计算量不能太小比如每个任务运行时间只有几毫秒进程间的创建和调度开销会吞噬加速效果。经验值建议单个任务至少运行几十毫秒以上。4.2 配合 asyncio 处理高并发I/O如果I/O并发量非常大比如同时发起上千个请求线程的数量不可能无限膨胀线程本身的创建和上下文切换成本不可忽视。这时asyncio是更好的答案。它用事件循环配合非阻塞I/O在单线程内实现了超高并发的异步调度。同样发1000个请求线程池可能需要几百个线程而asyncio几乎是单线程完成的资源占用要低很多。写异步代码时有一个容易犯的错在async函数里调用了同步阻塞库比如time.sleep或原生的requests.get整个事件循环会被卡住等于把异步打回串行。正确做法是用异步库的对应API比如await asyncio.sleep()、await session.get()。如果实在绕不开某些同步库可以把它丢到线程池里执行比如await loop.run_in_executor(None, sync_func, arg)。另外asyncio本身不涉及GIL抢占因为它在单线程内调度协程没有线程上下文切换的额外消耗但要区分协程的调度点必须是await的地方。4.3 由C扩展主动释放GIL的真香路线当计算量集中在某段非常密集的逻辑里比如图像处理、数值运算多进程的进程间通信和内存复制开销逐渐变大的时候可以考虑用C扩展把核心计算段包裹起来并在里面主动释放GIL。CPython提供了两个宏Py_BEGIN_ALLOW_THREADS和Py_END_ALLOW_THREADS位于C扩展内部在执行计算逻辑之前释放GIL执行完毕后重新获取。这样其他Python线程就有机会在这个计算过程中运行达到一定程度的并行。这种方案听起来高端实际在标准库里早就被广泛使用。比如hashlib计算摘要、zlib压缩解压、socket的收发数据很多耗时的C代码都嫌弃GIL碍事主动让出锁。如果你用Cython写扩展也可以用with nogil:语法包裹目标代码段Cython会自动帮你处理GIL的释放和重新获取。当然这个方案的改造门槛比前两个高需要对C/C和Python C API有一定了解但如果遇到真正需要极致性能的场景这条路带来的收益非常可观。开发时建议先写一个最小可用的扩展做验证确认GIL确实被释放了比如用多线程跑扩展函数和一段CPU计算时能观察到CPU占用明显提升再扩大改造范围。5. 排查实录与常见问题速查5.1 快速定位GIL问题的三板斧如果程序跑得很慢怀疑是GIL的问题怎么快速定位我总结了三步走的排查方法。第一步看CPU占用率。打开系统监控运行你的并发任务。如果任务是CPU密集型CPU总占用率却始终上不去比如8核机器总占用只有100%多一点那大概率是GIL在作祟因为只有一个线程真正在执行字节码。第二步做替换实验。把多线程实现临时替换成多进程实现如果性能大幅提升基本可以判定瓶颈在GIL。如果换成多进程也没太大改善问题可能出在算法本身或者数据竞争上别让GIL背锅。第三步可以用py-spy等性能剖析工具做实时采样py-spy可以输出每个Python线程当前正在执行的代码行。如果发现多个线程总是停在同一个CPU密集循环的附近并且频繁切换那GIL就是唯一的解释。数据说话比靠猜靠谱得多。5.2 常见问题速查表我把这几年踩过的坑整理成了一张速查表方便你在问题出现时快速对照。问题现象原因分析解决建议线程数和核数一样多CPU却跑不满纯计算任务受GIL限制无法并行改用ProcessPoolExecutor或Process多线程程序反而不如单线程快GIL切换和调度开销大于并发收益CPU密集任务首先考虑多进程而非多线程多线程写共享变量结果异常GIL只保证单条字节码的原子性不保证复合操作安全使用threading.Lock或queue等线程安全容器I/O密集场景用多线程效果不错线程阻塞时释放GIL等待可重叠放心用ThreadPoolExecutor可显著提速I/O并发量极大线程数量失控线程数过多切换和内存开销高改用asyncio或协程方案Windows下多进程程序无限创建进程spawn模式会重新导入主模块没有入口保护把启动代码放入ifname main:中再补充几个细节。第一别手动去调sys.setswitchinterval网上也有建议把切换间隔调大或调小来优化GIL实测下来收益微乎其微还可能导致部分线程长时间得不到执行出现响应延迟。第二GIL不等于线程安全这是一个很容易被误解的点。GIL只保证单个字节码指令执行时的内存安全两个线程同时对同一个变量做read-modify-write操作依然存在竞态条件必须加业务锁。第三如果Python程序里大部分计算都发生在numpy这类C扩展库里GIL的影响其实有限因为numpy执行向量化计算时会释放GIL这时线程并行可能有效果但同样需要实测验证。5.3 一个让性能翻倍的综合思路最后分享一个我在实际项目里用的组合策略。一个典型的数据批处理任务往往同时包含CPU计算和I/O等待比如先从数据库读取大量数据I/O密集再做复杂的特征计算CPU密集最后把结果写入网络接口I/O密集。面对混合型任务我把步骤拆开处理数据库读取和最终写入用ThreadPoolExecutor并发执行中间的特征计算用ProcessPoolExecutor分成多个进程并行如果再遇到高并发的网络调用就换asyncio事件循环处理。把不同性质的任务安排到合适的执行模型里整体的吞吐量比原来单一的多线程版提升了接近80%。性能优化不是空喊口号而是要找到瓶颈所在的资源类型然后对症下药。写到这里回看那次熬夜的经历我发现最大的收获其实不是几行优化过的代码而是一个习惯拿到任何Python并发需求先停下来判断任务属于CPU密集还是I/O密集再决定用线程、进程还是协程。GIL并没有那么可怕它只是迫使你更清楚地理解你手里的任务类型。如果你也正在被Python多线程没用这个问题折磨先别急着换语言或者重构把你的任务跑一遍前面那几段测试代码搞清楚GIL在什么场景下是瓶颈、什么场景下根本不是问题再动手调整方案。我也一直保留着那台测试机上的几份基准脚本每次接到新的并发需求都会先跑一遍当作决策依据。这个方法帮我少熬了无数次夜希望也能帮你省掉那几天本不该存在的加班时间。
Python多线程为何无效？深度解析GIL原理与绕开方案
Python的多线程就是个假把式。我第一次听到这句话是在一个周五晚上的加班现场。那时候我正蹲在工位上对着一台CPU占用率死活上不去的机器发呆。代码跑的是多线程批量任务数据量不大耗时却比单线程还久任务进度条卡在一个位置不动眼看着周六早上就要上线。带着满肚子怀疑我把Python并发机制从头翻了一遍才真正搞清楚GILGlobal Interpreter Lock全局解释器锁是怎么回事。这篇文章就是我连续熬了三天、踩了无数坑之后沉淀出来的结果想给所有写过Python多线程却觉得怎么没效果的朋友讲透GIL的底层逻辑也顺便给出我实测后一直在用的方案。无论你是写爬虫、做数据批处理还是处理高并发接口只要你在Python里碰过线程这篇文章都值得花十分钟看完。GIL这东西说简单也简单说复杂也复杂。简单到一句话就能概括CPython解释器同一时刻只允许一个线程执行Python字节码。复杂到它牵扯了内存管理、线程调度、C扩展、历史设计取舍任何一个地方都可能成为性能瓶颈的源头。网上聊GIL的帖子不少但大多只讲现象不讲原因更不给实操方案。我这篇会把整个来龙去脉拆开讲从原理到实测再到避坑一篇给你讲清楚。1. GIL到底锁了什么一个被误读的全局锁1.1 为什么Python多线程会被说成假把式在解释GIL之前先看一个几乎所有Python开发者都会遇到的现象。你写一个很纯粹的计算函数比如反复做数学运算然后开4个线程去跑相同任务结果总耗时和单线程跑4次几乎一样甚至还有可能更慢。你换成进程试试速度瞬间提上去。这个现象太反常了因为其他语言里多线程就是用来做并行计算的怎么到了Python这里就失效了于是Python的多线程是假把式这句话就在开发者群里流传开了。要理解这句话得先明白Python线程本身的属性。在CPython里threading模块创建的每个Thread底层都是真实的操作系统线程由操作系统负责调度。也就是说线程是真的并没有被做成伪线程。那么假在哪里假在它们无法同时执行Python代码。无论你创建多少个线程同一时刻只能有一个线程进入解释器执行字节码其他线程哪怕已经具备运行条件也只能在门外排队等待。这就造成了一种尴尬局面多线程的壳子装的是单线程的内核CPU密集任务不但没有加速反而多了调度开销。1.2 GIL的诞生与其合理性历史选择下的设计取舍为什么CPython要设计这样一个看起来毫无并发诚意的锁这得从Python的内存管理说起。CPython在管理对象生命周期时使用引用计数来追踪每个对象的存活状态。每当你创建一个新引用指向某个对象它的引用计数会1引用被销毁时-1当计数归零时解释器马上回收这块内存。问题来了如果有两个线程同时修改同一个对象的引用计数就可能出现计数错乱。比如一个线程正在将该对象计数从1减到0并回收内存另一个线程同时尝试增加引用计数这时这个对象实际已经不存在了程序轻则数据损坏重则直接崩溃。解决办法有很多最容易想到的是给每个对象都加一把细粒度锁但对象数量动辄百万千万锁内存开销和加锁开销都不小会让解释器整体性能大打折扣。于是CPython选择了一个简单粗暴却极其有效的思路在解释器级别加一把全局锁同一时刻只让一个线程跑Python字节码引用计数的问题从根本上就不存在了。从设计者的角度看这个方案在当时是相当务实的。Python本身并不是为了高性能并发而生的语言它的核心优势是开发效率。在GIL的保护下内存管理变得简单且稳定大量C扩展库可以省掉内部同步的功夫直接享受解释器提供的隐式线程安全。那个年代多核CPU还没有普及单线程性能对多数场景来说够用GIL带来的影响也就没有今天这么突出。1.3 为什么至今没移除GIL一个更现实的答案很多人可能会问既然GIL导致多线程无法真正并行Python官方为什么不把它干掉这个问题我当年也困惑了很久了解得越深越发现移除GIL远比想象中复杂。首先是技术工程量的原因。去掉GIL意味着CPython整个内存管理模型要推倒重来引用计数、垃圾回收、对象分配都必须引入细粒度锁来保证线程安全这项工作是十年甚至更长时间级别的不是改几行代码就能完成的。其次是单线程性能的代价。为了追求多线程并行而给所有数据结构都加锁很可能会让普通单线程程序的执行效率明显变慢而绝大多数Python脚本本来就是单线程的。用大多数用户的性能损失去换取少数并发场景的收益这个账并不划算。第三个原因是C扩展生态的兼容性。大量第三方库用C编写依赖GIL提供的保护比如numpy、pandas、opencv这些库在底层都大量运行计算密集型C代码。如果GIL消失这些库必须重新设计和验证线程安全问题工作量极大。PEP 703一直在探索无GIL的方向但距离在生产环境默认启用还有非常长的路。1.4 一个关键补充GIL不是啥都锁在深入GIL的时候很多人会陷入另一个误区认为GIL锁住了整个进程导致所有操作都无法并发。实际上GIL只锁Python字节码的执行而且锁的持有是有条件的。一旦线程进入阻塞等待状态比如等待网络数据返回、等待文件读写完成、调用了一些耗时较长且明确释放锁的C扩展接口解释器就会主动释放GIL让其他线程有机会运行。换句话说如果程序大部分时间都在等GIL并不会成为瓶颈多线程依然能获得可观的并发收益。这个特性是后面区分CPU密集与I/O密集任务的关键也是很多教程没讲透的地方。2. 分清任务类型CPU密集和I/O密集的岔路口2.1 先摆出来一条结论扯了这么多原理落到实操层面其实就一句话CPU密集型任务别用多线程直接用多进程I/O密集型任务多线程完全够用再配合asyncio性价比极高。判断你的任务属于哪一类是一切并发优化工作的起点。判断方法也很简单程序大多数时间在占用CPU做计算还是大多数时间在等待外部系统响应前者是CPU密集后者是I/O密集。比如循环一百万次求和、图像像素级处理、模型预测属于CPU密集批量网络请求、大量文件读写、频繁查询数据库属于I/O密集。2.2 I/O密集任务为什么能沾到多线程的光I/O密集的核心特征就是等待。程序发出一个网络请求后需要等待对方服务器返回数据这个等待过程普遍在几十毫秒到几秒之间线程在这种情况下处于阻塞态不消耗CPU。CPython对阻塞的处理非常聪明线程一旦进入阻塞等待GIL就会被释放别的线程立刻可以抢占执行权。也就是说虽然只有一个线程在跑字节码但等待的时间是可以互相重叠的。打个比方解释。单线程执行10个请求相当于你一个人去10个窗口排队办事每个窗口耗1秒总共10秒。多线程执行同样10个请求相当于找了10个朋友各排一个窗口大家同时等1秒多就能全部办完。因为大家在等待时都不占CPUGIL轮不轮得到根本不重要。这也是爬虫、接口调用这类场景用ThreadPoolExecutor能获得近乎线性加速的原因。我实测过用10个线程并发请求一个响应时间约0.5秒的接口总耗时从单线程的5秒压缩到0.8秒左右效果非常明显。2.3 CPU密集任务为什么越跑越慢CPU密集任务的性质完全不同整个执行过程中线程都在不断计算几乎没有主动阻塞等待的机会。此时GIL会被强制周期性地在线程之间切换保留现场、恢复现场、反复争夺锁的持有权每切换一次都要消耗时间和内存资源。从Python 3.2开始默认的切换间隔是5毫秒可以用sys.getswitchinterval()查看也就是说一个线程最多连续执行5毫秒就会被强制让出GIL下一个线程再执行5毫秒周而复始。多线程跑CPU密集任务从宏观视角看几个线程确实都在跑但微观上它们是在轮流使用同一个CPU核心的计算权而不是在多核上同时计算。除了刚刚提到的切换开销GIL竞争本身还会让线程频繁进入睡眠与唤醒状态系统调度开销全部变成额外成本。实测中4个线程跑同样的计算任务耗时不仅没有降低有时候比单线程跑4次还慢20%到40%。线程数量越多切换越频繁性能反而越差这就是假把式的真相。3. 实测现场还原三份代码看清GIL的脾气3.1 准备一个干净的测试环境光讲理论说服力不够我来还原一下当时实测的场景。测试机配置是8核CPU、16GB内存系统分别跑过Windows 10和Ubuntu 20.04Python版本是3.10结论在两个平台上基本一致。测试前建议关闭其他占用资源的程序每个用例跑5次取中位数避免偶发波动干扰判断。为了公平对比我设计了三个方向单线程、多线程、多进程分别针对CPU密集场景和I/O密集场景做计时。3.2 CPU密集对比threading vs multiprocessing vs 单线程基础测试代码如下一个累加平方数的纯计算函数cpu_task然后分别用单线程、多线程和多进程执行4次计时看结果。import time import threading from multiprocessing import Pool def cpu_task(n): total 0 for i in range(n): total i * i return total def run_single(rounds, n): start time.perf_counter() for _ in range(rounds): cpu_task(n) return time.perf_counter() - start def run_threads(rounds, n): threads [] start time.perf_counter() for _ in range(rounds): t threading.Thread(targetcpu_task, args(n,)) threads.append(t) t.start() for t in threads: t.join() return time.perf_counter() - start def run_processes(rounds, n): start time.perf_counter() with Pool(processesrounds) as pool: results [pool.apply_async(cpu_task, args(n,)) for _ in range(rounds)] for res in results: res.get() return time.perf_counter() - start if __name__ __main__: N 8_000_000 ROUNDS 4 print(f单线程耗时: {run_single(ROUNDS, N):.4f}s) print(f多线程耗时: {run_threads(ROUNDS, N):.4f}s) print(f多进程耗时: {run_processes(ROUNDS, N):.4f}s)我机器上跑出的典型结果是单线程约0.85秒多线程约1.02秒多进程约0.26秒。单线程反倒比多线程更快这还只是4个线程调度的开销。如果线程数增加到8个多线程的耗时还会继续上涨。而多进程充分利用4个CPU核心并行计算耗时接近单线程的四分之一加速比非常接近理论值。这一组数据足以说明CPU密集场景里GIL就是绕不过去的墙。3.3 I/O密集对比单线程 vs 线程池I/O密集的测试我用time.sleep来模拟网络请求等待原因很简单真实网络请求的响应时间波动太大不利于做可复现的结果对比。程序让每个任务睡眠1秒表示等待外部系统返回然后分别用单线程串行执行4次以及用4个线程并发执行4次统计总耗时。import time import threading from concurrent.futures import ThreadPoolExecutor def io_task(sec1): time.sleep(sec) return sec def run_single_io(rounds): start time.perf_counter() for _ in range(rounds): io_task() return time.perf_counter() - start def run_thread_pool_io(rounds): start time.perf_counter() with ThreadPoolExecutor(max_workersrounds) as executor: list(executor.map(io_task, [1] * rounds)) return time.perf_counter() - start if __name__ __main__: rounds 4 print(f单线程I/O耗时: {run_single_io(rounds):.4f}s) print(f线程池I/O耗时: {run_thread_pool_io(rounds):.4f}s)结果非常直观单线程耗时约4秒线程池耗时约1秒。也就是说在阻塞等待场景下4个线程几乎完美并行GIL几乎没有拖后腿。原理就是前面讲的线程阻塞时会释放GIL其他线程可以在等待期间交替运行。这也说明了为什么写爬虫时多线程仍然是一个极其有效的方案。4. 绕开GIL的实用方案多进程、线程池与协程4.1 ProcessPoolExecutor 的正确打开方式实际项目里直接用multiprocessing.Pool管理进程还是太原始了我更喜欢concurrent.futures里封装好的ProcessPoolExecutor接口和线程池几乎一致切换成本很低。from concurrent.futures import ProcessPoolExecutor def process_batch(items): with ProcessPoolExecutor(max_workers4) as executor: results list(executor.map(cpu_task, items)) return results使用时有三个实操细节需要注意。一是进程数不要盲目等于CPU核数如果机器上还有其他服务在跑建议留一两个核心给系统否则整体响应反而变慢。二是传给子进程的数据要尽量小涉及大数据集时优先考虑用共享内存或文件缓存而不是反复pickle序列化传输序列化开销一旦超过计算的收益多进程就得不偿失。三是粒度控制每个任务计算量不能太小比如每个任务运行时间只有几毫秒进程间的创建和调度开销会吞噬加速效果。经验值建议单个任务至少运行几十毫秒以上。4.2 配合 asyncio 处理高并发I/O如果I/O并发量非常大比如同时发起上千个请求线程的数量不可能无限膨胀线程本身的创建和上下文切换成本不可忽视。这时asyncio是更好的答案。它用事件循环配合非阻塞I/O在单线程内实现了超高并发的异步调度。同样发1000个请求线程池可能需要几百个线程而asyncio几乎是单线程完成的资源占用要低很多。写异步代码时有一个容易犯的错在async函数里调用了同步阻塞库比如time.sleep或原生的requests.get整个事件循环会被卡住等于把异步打回串行。正确做法是用异步库的对应API比如await asyncio.sleep()、await session.get()。如果实在绕不开某些同步库可以把它丢到线程池里执行比如await loop.run_in_executor(None, sync_func, arg)。另外asyncio本身不涉及GIL抢占因为它在单线程内调度协程没有线程上下文切换的额外消耗但要区分协程的调度点必须是await的地方。4.3 由C扩展主动释放GIL的真香路线当计算量集中在某段非常密集的逻辑里比如图像处理、数值运算多进程的进程间通信和内存复制开销逐渐变大的时候可以考虑用C扩展把核心计算段包裹起来并在里面主动释放GIL。CPython提供了两个宏Py_BEGIN_ALLOW_THREADS和Py_END_ALLOW_THREADS位于C扩展内部在执行计算逻辑之前释放GIL执行完毕后重新获取。这样其他Python线程就有机会在这个计算过程中运行达到一定程度的并行。这种方案听起来高端实际在标准库里早就被广泛使用。比如hashlib计算摘要、zlib压缩解压、socket的收发数据很多耗时的C代码都嫌弃GIL碍事主动让出锁。如果你用Cython写扩展也可以用with nogil:语法包裹目标代码段Cython会自动帮你处理GIL的释放和重新获取。当然这个方案的改造门槛比前两个高需要对C/C和Python C API有一定了解但如果遇到真正需要极致性能的场景这条路带来的收益非常可观。开发时建议先写一个最小可用的扩展做验证确认GIL确实被释放了比如用多线程跑扩展函数和一段CPU计算时能观察到CPU占用明显提升再扩大改造范围。5. 排查实录与常见问题速查5.1 快速定位GIL问题的三板斧如果程序跑得很慢怀疑是GIL的问题怎么快速定位我总结了三步走的排查方法。第一步看CPU占用率。打开系统监控运行你的并发任务。如果任务是CPU密集型CPU总占用率却始终上不去比如8核机器总占用只有100%多一点那大概率是GIL在作祟因为只有一个线程真正在执行字节码。第二步做替换实验。把多线程实现临时替换成多进程实现如果性能大幅提升基本可以判定瓶颈在GIL。如果换成多进程也没太大改善问题可能出在算法本身或者数据竞争上别让GIL背锅。第三步可以用py-spy等性能剖析工具做实时采样py-spy可以输出每个Python线程当前正在执行的代码行。如果发现多个线程总是停在同一个CPU密集循环的附近并且频繁切换那GIL就是唯一的解释。数据说话比靠猜靠谱得多。5.2 常见问题速查表我把这几年踩过的坑整理成了一张速查表方便你在问题出现时快速对照。问题现象原因分析解决建议线程数和核数一样多CPU却跑不满纯计算任务受GIL限制无法并行改用ProcessPoolExecutor或Process多线程程序反而不如单线程快GIL切换和调度开销大于并发收益CPU密集任务首先考虑多进程而非多线程多线程写共享变量结果异常GIL只保证单条字节码的原子性不保证复合操作安全使用threading.Lock或queue等线程安全容器I/O密集场景用多线程效果不错线程阻塞时释放GIL等待可重叠放心用ThreadPoolExecutor可显著提速I/O并发量极大线程数量失控线程数过多切换和内存开销高改用asyncio或协程方案Windows下多进程程序无限创建进程spawn模式会重新导入主模块没有入口保护把启动代码放入ifname main:中再补充几个细节。第一别手动去调sys.setswitchinterval网上也有建议把切换间隔调大或调小来优化GIL实测下来收益微乎其微还可能导致部分线程长时间得不到执行出现响应延迟。第二GIL不等于线程安全这是一个很容易被误解的点。GIL只保证单个字节码指令执行时的内存安全两个线程同时对同一个变量做read-modify-write操作依然存在竞态条件必须加业务锁。第三如果Python程序里大部分计算都发生在numpy这类C扩展库里GIL的影响其实有限因为numpy执行向量化计算时会释放GIL这时线程并行可能有效果但同样需要实测验证。5.3 一个让性能翻倍的综合思路最后分享一个我在实际项目里用的组合策略。一个典型的数据批处理任务往往同时包含CPU计算和I/O等待比如先从数据库读取大量数据I/O密集再做复杂的特征计算CPU密集最后把结果写入网络接口I/O密集。面对混合型任务我把步骤拆开处理数据库读取和最终写入用ThreadPoolExecutor并发执行中间的特征计算用ProcessPoolExecutor分成多个进程并行如果再遇到高并发的网络调用就换asyncio事件循环处理。把不同性质的任务安排到合适的执行模型里整体的吞吐量比原来单一的多线程版提升了接近80%。性能优化不是空喊口号而是要找到瓶颈所在的资源类型然后对症下药。写到这里回看那次熬夜的经历我发现最大的收获其实不是几行优化过的代码而是一个习惯拿到任何Python并发需求先停下来判断任务属于CPU密集还是I/O密集再决定用线程、进程还是协程。GIL并没有那么可怕它只是迫使你更清楚地理解你手里的任务类型。如果你也正在被Python多线程没用这个问题折磨先别急着换语言或者重构把你的任务跑一遍前面那几段测试代码搞清楚GIL在什么场景下是瓶颈、什么场景下根本不是问题再动手调整方案。我也一直保留着那台测试机上的几份基准脚本每次接到新的并发需求都会先跑一遍当作决策依据。这个方法帮我少熬了无数次夜希望也能帮你省掉那几天本不该存在的加班时间。
