一个让程序员崩溃的深夜加班经历

凌晨一点，盯着屏幕上那份跑了快两个小时的数据处理程序，心态确实有点崩了。

事情是这样的。公司有一批大约五千万条的日志文件需要清洗和解析，每行数据要做正则匹配、字段提取、格式转换。笔记本电脑是八核的，想着Python多线程不是能充分利用多核处理器吗？开八个线程同时干，速度起码能快个四五倍吧？

于是花半小时改好了代码，信心满满地跑起来。

结果呢？八线程版本跑完花了整整十分钟。而单线程版本，只用了九分半。

没错，多线程比单线程还慢。

那种感觉就像花钱升级了八车道的高速公路，结果车流全堵在收费口，跟单车道没什么区别，甚至还更堵了。

任务管理器里只有一个核心满负荷、其他核心几乎在“看戏”的状态，让人猛然想起一个很久以前听说过、但从来没认真对待的词——GIL。

今天就把这个坑从头到尾讲清楚。不讲高深的理论，只说人话，让以后写Python并发代码的时候，知道什么时候该用多线程，什么时候该绕道走。

GIL到底是什么鬼东西

GIL，全称叫Global Interpreter Lock，中文是“全局解释器锁”。

可以把它理解成Python解释器门口的一个“门禁卡”，而且整栋楼只有这一张卡。

规则很简单：任何一个线程想要执行Python代码，必须先拿到这张门禁卡。拿到之后，其他线程就只能在大楼外面等着。等这个线程执行一小段时间（或者主动释放），门禁卡才会传给下一个线程。

也就是说，在同一个进程里，无论你开了多少个线程，同一时刻最多只有一个线程在真正执行Python代码。

这就是为什么八核电脑跑Python多线程，只有一个核心在干活的原因——不是硬件不行，是GIL这只拦路虎死死守着那扇门。

有人可能会问：那多线程还有什么用？不就跟单线程一样吗？

别急，GIL并不是在所有情况下都是坏蛋。它其实是个“两害相权取其轻”的设计。

为什么Python要设计GIL

很多人以为GIL是Python的一个愚蠢设计失误，其实不是。

时间倒回到上世纪90年代，Python刚诞生的时候，计算机基本都是单核的，多核CPU是后来的事。当时Python的设计者Guido van Rossum面临一个很现实的问题：如何实现内存管理？

Python内部会记录每个对象被引用了多少次（这叫引用计数），当引用次数归零时，就释放这块内存。在多线程环境下，两个线程可能同时修改同一个对象的引用计数，如果不加保护，计数就会出错，导致内存泄漏或者程序崩溃。

解决方案有两个：

方案一：给每个对象单独加锁。但这意味着每操作一个对象都要获取释放锁，开销巨大，而且容易产生死锁。

方案二：在整个解释器层面加一把大锁。任何线程执行Python代码都必须先拿到这把锁。实现简单，性能在单核时代也完全够用。

Python选择了方案二，这就是GIL的由来。

在单核年代，这个设计非常合理。多线程其实是通过时间片轮换来模拟“同时运行”的，GIL并没有造成实质性的性能损失。直到多核CPU普及，这个设计才变成一个问题。

打个比方：GIL就像一条单车道隧道的交通信号灯。车不多的时候，有信号灯反而更安全，大家有序通过。但车流量大了之后，明明双向八车道的高速公路，到了隧道口还是只能一辆一辆地过，这就成了瓶颈。

GIL到底影响什么

为了直观感受GIL的影响，用一个最简单的例子测试一下。

任务：计算从1加到1亿的累加和。

单线程版本：

import time

def count():
total = 0
for i in range(100_000_000):
total = i
return total

start = time.time()
result = count()
print(f"耗时: {time.time() - start:.2f}秒")


机器上跑出来大约是5.6秒。

多线程版本（4个线程）：

import time
import threading

def count(start, end, result, index):
total = 0
for i in range(start, end):
total = i
result[index] = total

start_time = time.time()
threads = []
results = [0, 0, 0, 0]
step = 25_000_000 # 1亿分成4份

for i in range(4):
start = i * step
end = (i 1) * step
t = threading.Thread(target=count, args=(start, end, results, i))
threads.append(t)
t.start()

for t in threads:
t.join()

print(f"耗时: {time.time() - start_time:.2f}秒")
print(f"结果: {sum(results)}")


跑出来是多少？大约6.1秒。

多线程反而更慢，慢了将近10%。

为什么会这样？四个线程轮流抢GIL，频繁的线程切换带来了额外开销。每个线程拿到GIL后执行一小会儿就被迫让出，这种“上下文切换”是有成本的。线程越多，切换越频繁，额外开销越大，速度反而越慢。

这种任务叫“CPU密集型任务”——主要是消耗CPU计算能力的。在CPU密集型任务上，Python多线程不仅没用，反而有害。

那多线程在什么时候有用

别急着判死刑。Python多线程有一个场景非常好用：I/O密集型任务。

什么叫I/O密集型？就是程序大部分时间不是在计算，而是在等待。

比如：

这些操作的特点是：CPU大部分时间在“闲着”，真正干活的是硬盘、网卡这些硬件。发出请求之后，程序就在那里干等着，等数据返回后才继续执行。

这种情况下，多线程就能派上大用场了。

举个实际例子。假设要用requests库调用100个HTTP接口，每个接口响应时间大约0.5秒。

单线程版本：发出请求 → 等0.5秒 → 收到响应 → 发下一个请求。100个请求串行执行，总耗时 ≈ 50秒。

多线程版本：开10个线程，每个线程负责10个请求。发出请求后，线程A等着的时候，GIL会释放给线程B，线程B继续发请求。这样基本上所有请求可以同时发出，总耗时 ≈ 0.5秒（并行等待时间） 少量网络开销，可能也就1秒左右。

差距是50倍。

下面是一个简单的演示代码，模拟网络请求：

import time
import threading
import random

def simulate_api_call(thread_id):
"""模拟一个耗时0.5秒左右的API调用"""
print(f"线程{thread_id}: 开始请求...")
time.sleep(0.5) # 模拟网络等待
print(f"线程{thread_id}: 请求完成")

# 单线程
start = time.time()
for i in range(20):
simulate_api_call(i)
print(f"单线程耗时: {time.time() - start:.2f}秒")

# 多线程
start = time.time()
threads = []
for i in range(20):
t = threading.Thread(target=simulate_api_call, args=(i,))
threads.append(t)
t.start()
for t in threads:
t.join()
print(f"多线程耗时: {time.time() - start:.2f}秒")


运行结果：

单线程耗时: 10.05秒
多线程耗时: 0.52秒


这差距就非常明显了。

为什么I/O密集任务多线程有效？因为当线程A发起网络请求后，CPU不需要做任何事，只需要等待网卡返回数据。线程A在等待期间会主动释放GIL，操作系统就可以调度其他线程去执行。等到网卡收到数据，线程A会重新抢GIL继续执行。

所以核心原理就是：GIL只在执行Python代码时被占用，当线程处于I/O等待状态时，GIL是释放的。这就给了其他线程执行的机会，实现了“伪并行”。

如何绕过GIL的限制

如果确实需要并行执行CPU密集型任务，怎么办？有三种主流方案。

方案一：使用多进程（multiprocessing）

既然GIL只在一个进程内生效，那开多个进程不就行了？每个进程有自己独立的GIL，互不干扰。

Python的multiprocessing模块就是干这个的：

from multiprocessing import Pool
import time

def count(n):
total = 0
for i in range(n):
total = i
return total

if __name__ == '__main__':
# 单进程
start = time.time()
count(100_000_000)
print(f"单进程: {time.time() - start:.2f}秒")

# 多进程（4个进程）
start = time.time()
with Pool(4) as pool:
results = pool.map(count, [25_000_000] * 4)
print(f"多进程: {time.time() - start:.2f}秒")


运行结果：

单进程: 5.6秒
多进程: 1.6秒


这才是真正发挥了多核的优势，接近线性的加速比。

不过多进程也有代价：进程间通信成本高（不像线程间可以直接共享数据），创建进程开销也大，内存占用更高。适合计算量大、数据相对独立的任务。

方案二：使用C扩展或NumPy

很多Python科学计算库（比如NumPy、Pandas）的核心计算部分是用C语言写的。C语言代码在执行时，可以主动释放GIL。

这就是为什么用NumPy做大矩阵乘法，速度飞快——计算工作实际上在C层面并行执行的，绕过了GIL。

import numpy as np
import time

# 纯Python矩阵乘法
def python_matrix_multiply(size):
A = [[1.0] * size for _ in range(size)]
B = [[1.0] * size for _ in range(size)]
result = [[0.0] * size for _ in range(size)]
for i in range(size):
for j in range(size):
for k in range(size):
result[i][j] = A[i][k] * B[k][j]

# NumPy矩阵乘法（底层C实现）
def numpy_matrix_multiply(size):
A = np.ones((size, size))
B = np.ones((size, size))
result = np.dot(A, B)

# 自己跑跑看，差距可能上百倍


方案三：换一个没有GIL的解释器

CPython（官方Python解释器）有GIL，但不代表所有Python解释器都有。

对于绝大多数开发者来说，官方CPython 多进程方案是最成熟的选择。

总结：什么时候用多线程

用一张简单的表格来总结：

另外补充一句：对于I/O密集型任务，asyncio（异步IO）往往比多线程性能更好、资源占用更低。但asyncio的学习曲线比较陡，需要理解async/await语法和事件循环的概念。如果只是想快速解决I/O并发问题，多线程是最简单直接的选择。

彩蛋：看看GIL长什么样

Python的sys模块里有一个开关，可以检查GIL的状态（虽然不能关掉它）。

import sys
print(sys._is_gil_enabled()) # 通常输出True


从Python 3.13开始，官方提供了一个实验性的“禁用GIL”的编译选项（叫自由线程模式，free-threaded mode）。这是一个重大变化，但距离生产环境可用还需要几年时间。即便未来GIL可选的版本成熟了，大部分现有的Python代码和C扩展库也需要重新适配。

所以在那一天到来之前，还是得学会和GIL和平共处——要么用多进程，要么用asyncio，要么把计算任务交给NumPy这样的C库。

别再像那天凌晨一样，傻傻地以为开八个线程就能让代码飞起来了。写代码这件事，知其然还要知其所以然，才能绕过那些看似不起眼、实则能坑你一晚上的陷阱。

希望这篇文章能帮你省下一晚的加班时间。