Python 多线程居然是 —— 假的？

十全十美

我们知道 Python 之所以灵活和强大，是因为它是一个解释性语言，边解释边执行，实现这种特性的标准实现叫作 CPython。

它分两步来运行 Python 程序：

• 首先解析源代码文本，并将其编译为字节码（bytecode）[1]
• 然后采用基于栈的解释器来运行字节码
• 不断循环这个过程，直到程序结束或者被终止

灵活性有了，但是为了保证程序执行的稳定性，也付出了巨大的代价：

引入了 全局解释器锁GIL（global interpreter lock）[2]

以保证同一时间只有一个字节码在运行，这样就不会因为没用事先编译，而引发资源争夺和状态混乱的问题了。

看似 “十全十美” ，但，这样做，就意味着多线程执行时，会被 GIL 变为单线程，无法充分利用硬件资源。

来看代码：

import time
def gcd(pair):
    '''
    求解最大公约数
    '''
    a, b = pair
    low = min(a, b)
    for i in range(low, 0, -1):
        if a % i == 0 and b % i == 0:
            return i
    assert False, "Not reachable"
# 待求解的数据
NUMBERS = [
    (1963309, 2265973), (5948475, 2734765),
    (1876435, 4765849), (7654637, 3458496),
    (1823712, 1924928), (2387454, 5873948),
    (1239876, 2987473), (3487248, 2098437),
    (1963309, 2265973), (5948475, 2734765),
    (1876435, 4765849), (7654637, 3458496),
    (1823712, 1924928), (2387454, 5873948),
    (1239876, 2987473), (3487248, 2098437),
    (3498747, 4563758), (1298737, 2129874)
]
## 顺序求解
start = time.time()
results = list(map(gcd, NUMBERS))
end = time.time()
delta = end - start
print(f'顺序执行时间: {delta:.3f} 秒')

• 函数 gcd 用于求解最大公约数，用来模拟一个数据操作
• NUMBERS 为待求解的数据
• 求解方式利用 map 方法，传入处理函数 gcd, 和待求解数据，将返回一个结果数列，最后转化为 list
• 将执行过程的耗时计算并打印出来

在笔者的电脑上（4核，16G）执行时间为 2.043 秒。

如何换成多线程呢？

...
from concurrent.futures import ThreadPoolExecutor
...
## 多线程求解
start = time.time()
pool = ThreadPoolExecutor(max_workers=4)
results = list(pool.map(gcd, NUMBERS))
end = time.time()
delta = end - start
print(f'执行时间: {delta:.3f} 秒')

• 这里引入了 concurrent.futures 模块中的线程池，用线程池实现起来比较方便
• 设置线程池为 4，主要是为了和 CPU 的核数匹配
• 线程池 pool 提供了多线程版的 map，所以参数不变

看看运行效果：

顺序执行时间: 2.045 秒
并发执行时间: 2.070 秒

what?

并行执行的时间竟然更长了！

连续执行多次，结果都是一样的，也就是说在 GIL 的限制下，多线程是无效的，而且因为线程调度还多损耗了些时间。

戴着镣铐跳舞

难道 Python 里的多线程真的没用吗？

其实也并不是，虽然了因为 GIL，无法实现真正意义上的多线程，但，多线程机制，还是为我们提供了两个重要的特性。

一：多线程写法可以让某些程序更好写

怎么理解呢？

如果要解决一个需要同时维护多种状态的程序，用单线程是实现是很困难的。

比如要检索一个文本文件中的数据，为了提高检索效率，可以将文件分成小段的来处理，最先在那段中找到了，就结束处理过程。

用单线程的话，很难实现同时兼顾多个分段的情况，只能顺序，或者用二分法执行检索任务。

而采用多线程，可以将每个分段交给每个线程，会轮流执行，相当于同时推荐检索任务，处理起来，效率会比顺序查找大大提高。

二：处理阻塞型 I/O 任务效率更高

阻塞型 I/O 的意思是，当系统需要与文件系统（也包括网络和终端显示）交互时，由于文件系统相比于 CPU 的处理速度慢得多，所以程序会被设置为阻塞状态，即，不再被分配计算资源。

直到文件系统的结果返回，才会被激活，将有机会再次被分配计算资源。

也就是说，处于阻塞状态的程序，会一直等着。

那么如果一个程序是需要不断地从文件系统读取数据，处理后在写入，单线程的话就需要等等读取后，才能处理，等待处理完才能写入，于是处理过程就成了一个个的等待。

而用多线程，当一个处理过程被阻塞之后，就会立即被 GIL 切走，将计算资源分配给其他可以执行的过程，从而提示执行效率。

有了这两个特性，就说明 Python 的多线程并非一无是处，如果能根据情况编写好，效率会大大提高，只不过对于计算密集型的任务，多线程特性爱莫能助。

曲线救国

那么有没有办法，真正的利用计算资源，而不受 GIL 的束缚呢？

当然有，而且还不止一个。

先介绍一个简单易用的方式。

回顾下前面的计算最大公约数的程序，我们用了线程池来处理，不过没用效果，而且比不用更糟糕。

这是因为这个程序是计算密集型的，主要依赖于 CPU，显然会受到 GIL 的约束。

现在我们将程序稍作修改：

...
from concurrent.futures import ProcessPoolExecutor
...
## 并行程求解
start = time.time()
pool = ProcessPoolExecutor(max_workers=4)
results = list(pool.map(gcd, NUMBERS))
end = time.time()
delta = end - start
print(f'并行执行时间: {delta:.3f} 秒')

看看效果：

顺序执行时间: 2.018 秒
并发执行时间: 2.032 秒
并行执行时间: 0.789 秒

并行执行提升了将近 3 倍！什么情况？

仔细看下，主要是将多线程中的 ThreadPoolExecutor 换成了 ProcessPoolExecutor，即进程池执行器。

在同一个进程里的 Python 程序，会受到 GIL 的限制，但不同的进程之间就不会了，因为每个进程中的 GIL 是独立的。

是不是很神奇？这里，多亏了 concurrent.futures 模块将实现进程池的复杂度封装起来了，留给我们简洁优雅的接口。

这里需要注意的是，ProcessPoolExecutor 并非万能的，它比较适合于 数据关联性低，且是 计算密集型 的场景。

如果数据关联性强，就会出现进程间 “通信” 的情况，可能使好不容易换来的性能提升化为乌有。

处理进程池，还有什么方法呢？那就是：

用 C 语言重写一遍需要提升性能的部分

不要惊愕，Python 里已经留好了针对 C 扩展的 API。

但这样做需要付出更多的代价，为此还可以借助于 SWIG[3] 以及 CLIF[4] 等工具，将 python 代码转为 C。

有兴趣的读者可以研究一下。

自强不息

了解到 Python 多线程的问题和解决方案，对于钟爱 Python 的我们，何去何从呢？

有句话用在这里很合适：

求人不如求己

哪怕再怎么厉害的工具或者武器，都无法解决所有的问题，而问题之所以能被解决，主要是因为我们的主观能动性。

对情况进行分析判断，选择合适的解决方案，不就是需要我们做的么？

对于 Python 中 多线程的诟病，我们更多的是看到它阳光和美的一面，而对于需要提升速度的地方，采取合适的方式。这里简单总结一下：

1. I/O 密集型的任务，采用 Python 的多线程完全没用问题，可以大幅度提高执行效率
2. 对于计算密集型任务，要看数据依赖性是否低，如果低，采用 ProcessPoolExecutor 代替多线程处理，可以充分利用硬件资源
3. 如果数据依赖性高，可以考虑将关键的地方该用 C 来实现，一方面 C 本身比 Python 更快，另一方面，C 可以之间使用更底层的多线程机制，而完全不用担心受 GIL 的影响
4. 大部分情况下，对于只能用多线程处理的任务，不用太多考虑，之间利用 Python 的多线程机制就好了，不用考虑太多

总结

没用十全十美的解决方案，如果有，也只能是在某个具体的条件之下，就像软件工程中，没用银弹一样。

面对真实的世界，只有我们自己是可以依靠的，我们通过学习了解更多，通过实践，感受更多，通过总结复盘，收获更多，通过思考反思，解决更多。这就是我们人类不断发展前行的原动力。

为了我们美好的明天，为了人类美好的明天，加油！

比心！

参考代码

https://github.com/JustDoPython/python-examples/tree/master/taiyangxue/fake-thread

[1]

字节码: https://baike.baidu.com/item/%E5%AD%97%E8%8A%82%E7%A0%81/9953683

[2]

GIL: https://wiki.python.org/moin/GlobalInterpreterLock

[3]

SWIG: https://github.com/swig/swig

[4]

CLIF: https://github/google/clif