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

最近有位读者提问:

Python 的多线程真是假的吗?

一下子点到了 Python 长期被人们喜忧参半的特性 —— GIL 上了。

到底是怎么回事呢?今天我们来聊一聊。

十全十美

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

它分两步来运行 Python 程序:

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

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

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

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

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

来看代码:

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

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

在笔者的电脑上(4核,16G)执行时间为 2.043 秒。

如何换成多线程呢?

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

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

看看运行效果:

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

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

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

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

戴着镣铐跳舞

 

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

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

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

怎么理解呢?

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

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

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

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

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

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

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

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

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

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

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

曲线救国

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

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

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

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

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

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

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

看看效果:

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

并行执行提升了将近 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 的多线程机制就好了,不用考虑太多

总结

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

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

为了我们美好的明天,为了人类美好的明天,加油!

比心!

 

相关新闻

历经多年发展,已成为国内好评如潮的Linux云计算运维、SRE、Devops、网络安全、容器云、Go、Python开发专业人才培训机构!