当前位置：首页 > news >正文

Python的GIL把我坑惨了，原来多线程和多进程的区别这么大

news 2026/7/22 15:48:25

一个让我怀疑人生的性能优化

前年接了一个图像批处理项目。每天有上万张商品图片需要做缩放、水印和格式转换。我心想：“这还不简单？多线程并行处理，分分钟搞定。”

代码写得行云流水：

import threading from PIL import Image def process_image(image_path): img = Image.open(image_path) img = img.resize((800, 800)) # 加水印、转格式... img.save(f"processed_{image_path}") images = get_all_images() # 一万张图 threads = [] for path in images: t = threading.Thread(target=process_image, args=(path,)) t.start() threads.append(t) for t in threads: t.join()

开了20个线程，信心满满地跑起来。结果一看CPU监控——8核的服务器，CPU使用率只有25%左右，跟单线程跑没啥区别。处理速度也没快多少，一万张图还是跑了好几个小时。

同事路过看了一眼：“你用多线程跑CPU密集型任务？不知道GIL吗？”

我：“GIL是什么？”

那天下午，我把GIL、多线程和多进程的区别彻底研究了一遍。今天把这些东西讲清楚，希望你下次遇到类似问题别像我一样白忙活。

第一步：GIL到底是什么？

GIL的全称是Global Interpreter Lock，全局解释器锁。它是CPython解释器（就是咱们平时用的那个Python）里的一个互斥锁机制。

它的作用简单粗暴：同一时刻，只有一个线程能执行Python字节码。

也就是说，即使你的电脑有8核16核，跑Python多线程程序的时候，同一时间只有一个核心在工作，其他核心都在旁边看着。

听到这儿你可能想骂人了：“那Python的多线程不就是个摆设吗？”

别急，事情没那么简单。

第二步：GIL为什么存在？

GIL不是Python设计者脑子进水搞出来的东西。恰恰相反，它是一个有意为之的设计决策。

Python的内存管理用的是引用计数——每个Python对象都有一个计数器，记录有多少个地方引用了它。当计数器归零时，对象就被回收了。

问题来了：在多线程环境下，如果两个线程同时修改同一个对象的引用计数，就会出现竞争条件——计数可能只增加了一次而不是两次，导致对象永远无法被回收，造成内存泄漏。

解决这个问题有两种方案：

给每个对象加锁——细粒度锁，性能好但实现极其复杂，容易死锁
给整个解释器加一把大锁——简单粗暴，但限制了并行

Python选择了方案二。GIL就像是一个门卫，牢牢掌控着Python字节码的执行权，确保同一时刻只有一个线程能进门。

在单核CPU时代，这个设计完全没问题——反正同一时间本来就只有一个线程能用CPU。但多核普及之后，GIL就成了Python多线程的“紧箍咒”。

第三步：多线程到底有没有用？

有用，但要看场景。

GIL只限制Python字节码的执行。当线程执行I/O操作（比如网络请求、文件读写、数据库查询）时，它会主动释放GIL。其他等待的线程就可以趁机获取GIL并执行。

这就好比一个食堂只有一个打饭窗口（GIL）。如果你要做的只是“站在窗口前等饭”（I/O等待），那多几个人排队也没问题——反正大家都在等，谁先谁后差别不大。但如果你要做的是一人霸占窗口做复杂操作（CPU计算），那其他人就只能干等着。

I/O密集型任务（网络爬虫、文件读写、数据库操作）：多线程很有效

线程大部分时间在等待外部响应，不占用CPU
等待时释放GIL，其他线程可以运行
实测：20个网络请求，4线程比单线程快约4倍

CPU密集型任务（图像处理、数值计算、加密解密）：多线程基本没用

线程一直在执行计算，不释放GIL
多个线程轮流抢一把锁，加上切换开销，可能比单线程还慢
实测：计算质数，4线程比单线程还慢0.5秒

有测试数据显示：在4核CPU上跑CPU密集型任务，单线程耗时10.2秒，4线程耗时10.0秒——几乎没有提升。多出来的线程除了抢锁和切换上下文，什么都没干。

第四步：多进程——绕过GIL的真正并行

既然多线程被GIL卡死了，那怎么办？

答案是多进程。

每个Python进程都有自己独立的解释器和独立的内存空间。每个进程都有自己的GIL，互不干扰。所以在多核CPU上，多个进程可以真正做到同时运行——一个进程跑在一个核心上。

用多进程改造一下我的图像处理代码：

from multiprocessing import Pool def process_image(image_path): # 同样的处理逻辑 pass if __name__ == "__main__": images = get_all_images() with Pool(8) as p: # 8核CPU开8个进程 p.map(process_image, images)

改完之后，CPU使用率直接飙到95%以上，处理时间从几个小时缩短到了几十分钟。

实测数据更能说明问题：在4核CPU上计算100万以内质数，单线程3.2秒，4线程反而要6.1秒（线程切换开销+GIL竞争），但4进程只用了1.8秒，接近4倍加速。另一个测试显示，4进程方案在4核CPU上能达到3.66倍的加速比。

多进程的好处：

真正利用多核CPU
没有GIL干扰
每个进程内存隔离，不会相互影响

多进程的代价：

进程创建开销大（约100微秒到1毫秒，线程只需1-5微秒）
进程间通信需要序列化（pickle），比较麻烦
内存占用大——100个线程增加约15MB内存，100个进程增加约800MB
数据共享不如线程方便

第五步：到底该选哪个？

一张图说清楚：

场景	推荐方案	原因
网络爬虫、API调用	多线程	I/O等待时释放GIL，轻量高效
文件读写、数据库操作	多线程	同上
图像/视频处理	多进程	CPU密集型，需要真并行
数值计算、机器学习	多进程	充分利用多核
加密解密、压缩解压	多进程	CPU密集型