为什么 Python 多线程无法利用多核？
共 3886字，需浏览 8分钟
·
2020-11-02 07:30
剧照：凡人修仙传
作者：后端技术指南针
来源：后端技术指南针
1.全局解释锁
如题: Python的多线程为什么不能利用多核处理器？
全局解释器锁(Global Interpreter Lock)是计算机程序设计语言解释器用于同步线程的一种机制，它使得任何时刻仅有一个线程在执行。
即便在多核处理器上，使用 GIL 的解释器也只允许同一时间执行一个线程，常见的使用 GIL 的解释器有CPython与Ruby MRI。
可以看到GIL并不是Python独有的特性，是解释型语言处理多线程问题的一种机制而非语言特性。
2.Python的解释器
Python是一门解释器语言，代码通过解释器执行，Python存在多种解释器，分别基于不同语言开发，每个解释器有不同的特点。
Python程序的解释和执行过程简图:
CPython
CPython是主流版本的解释器，这个解释器是使用C语言编写的，也是使用最为广泛的解释器，可以方便地和C/C++的类库进行交互，因此也是最受关注的解释器。
Jython
一种由java语言编写的python解释器，是将python编译成Java字节码然后执行的一种解释器，可以方便地和Java的类库进行交互。
IronPython
将Python代码解释为.Net平台上运行的字节码进行执行，类似Jython解释器，可以方便的和.Net平台上的类库进行交互。IPython
在交互效果上有所增强，但执行过程和功能方面和CPython是一样的。
PyPy
一种使用JIT(just-in-time)技术的编译器，专注于执行速度，对Python代码进行动态编译，从而提高Python的执行速度。
PyPy在处理python代码的过程中，一小部分功能的处理和CPython的执行结果是有差异的，如果项目中要使用PyPy来进行执行效率的提升的话，一定要事先了解下PyPy和CPython的区别。
3.CPython的线程不安全
CPython的线程是操作系统的原生线程，在Linux的pthread完全由操作系统调度执行。
pthread本身不是线程安全的，需要使用者通过锁来实现多线程的安全运行，因此CPython解释器下的Python实现多线程也必然存在线程不安全的问题。
这就为GIL在多核时代的使用埋下了隐患。
4.GIL产生背景和挑战
Python是Guido van Rossum 在1989年发布的，那个时候计算机的主频还没有达到1G，程序全部都是运行在单核计算机上面，直到2005年多核处理器才被Intel开发出来。
Python各版本发布时间轴:
4.1 多核化对软件系统的冲击
戈登·摩尔 1965 年预测，每个集成电路的元件数量每 18 到 24 个月就会翻一倍，它的适用性预计会持续到 2015-2020 年。
摩尔定律未失效前软件系统可以单纯借助硬件的进步来获得性能的提升或者只需少量改进，就可以坐享性能飞跃。
然而从 2005 年开始，时钟速率的增长和晶体管数量的增长已不再同步。
由于处理器材料的物理性质限制，时钟速率已停止增长甚至下降，处理器制造商开始将更多执行单元核心封装到单个芯片中。
这一趋势给应用程序开发和编程语言设计带来越来越大的压力。
程序员和编程语言决策者不得不考虑如何快速适应多核硬件，来提高软件性能和编程语言的市场占有率，Python也不例外受到冲击。
4.2 多核化对CPython的冲击
在单核时代，崇尚优美、清晰、简单的吉多.范罗苏姆选择在解释器层面实现了一把全局互斥锁，来保护Python对象从而实现对单核CPU的使用率，这种做法在单核时代很奏效。
倘若在单核时未选择GIL，那么开发者就需要自己实现任务的管理，这样做对于CPU的利用率提高无法做到极致。
图为Python之父吉多.范罗苏姆:
但是随着多核时代的到来，高效地利用CPU 核心的有效方法就是使用并行性，多线程是充分实现并行的好方法，但是CPython的GIL却阻碍了对多核CPU的利用。
4.3 痛并快乐着的GIL
CPython的GIL给使用者带来了便利，并且在GIL的基础上开发了许多重要的Package和语言功能。
但是多核CPU的普适和其他语言对Python的冲击，让GIL显得原始而粗暴，无法有效利用多核处理器成为了弊端。
5.多核时代GIL暴露的问题
要搞清楚GIL对多线程程序的影响就要了解GIL的运行基本原理。
单核CPU情况
CPython的Pthread是通过操作系统调度算法调度执行。
Python解释器每执行一定数量的字节码，或遇到系统IO时，会强制释放GIL，然后触发一次操作系统的线程调度，实现单核CPU的充分利用，并且在单核上释放和重新执行的时间间隔非常短。
多核CPU情况
多核情况下多线程执行时，一个线程在CPU-A执行完之后释放GIL，其他CPU上的线程都会进行竞争，但CPU-A可能又马上获取到了GIL。
这就导致其他CPU上被唤醒的线程只能眼巴巴地看着CPU-A上的线程再次执行，而自己只能等待，直到又被切换到待调度的状态。
这就会产生多核CPU频繁进行线程切换，消耗着资源，但只有一个线程能够拿到GIL真正执行Python代码，这就导致多线程在多核CPU情况下，效率还不如单线程执行效率高。
这种情况非常类似于网络编程中的多个线程监听同一端口造成的惊群现象，只不过是CPU级别的，造成的浪费更加奢侈。
6.GIL的实际影响
I/O密集型
在单核CPU上执行多线程时由解释器实现了有效的切换，这一点是很有益处的。
在I/O密集型的诸如网络爬虫等类型的程序即使使用GIL控制下的多线程程序性能也不会像你想象中那么糟糕。
CPU密集型
对于CPU密集型的计算类程序GIL就有比较大的问题，因为CPU密集型的程序本身没有太多等待，不需要解释器介入并且所有任务只能等待1个核心，其他核心空闲也无法使用，这么看对多核的使用确实很糟糕。
7.抛弃和优化GIL
GIL一直备受争议，为此PEP也多次尝试删除或者优化GIL，但是解释器本身的复杂性和众多GIL下的类库都让GIL移除成为遥不可及的想法。
移除GIL
在1999年针对Python 1.5，一个free threading补丁已经尝试实现了这个想法，该补丁来自Greg Stein。
在这个补丁中，GIL被完全的移除，且用细粒度的锁来代替。然而，GIL的移除给单线程程序的执行速度带来了一定的代价。
当用单线程执行时，速度大约降低了40%。使用两个线程展示出了在速度上的提高，但除了这个提高，这个收益并没有随着核数的增加而线性增长。由于执行速度的降低，这一补丁被拒绝了，并且几乎被人遗忘。
1999年多核还是个幻想，但是在现今移除GIL也异常困难，真的移除效果如何也是未知的，只能说回头太难。
优化GIL
2009年Antoine Pitrou 在Python 3.2中实现了一个新的GIL，并且带着一些积极的结果。
这是GIL的一次最主要改变，旧的GIL通过对Python指令进行计数来确定何时放弃GIL。
单条Python指令将会包含大量的工作，在新的GIL实现中，用一个固定的超时时间来指示当前的线程以放弃这个锁，使得线程间的切换更加可预测。
8.GIL缺陷的解决方案
python作为生命力极强的热门语言，绝对不会在多核时代坐以待毙。即便有GIL的限制，仍然有许多方法让程序拥抱多核。
多进程
Python2.6引入了MultiProcess库来弥补Threading库中GIL带来的缺陷，基于此开发多进程程序，每个进程有单独的GIL,避免多进程之间对GIL的竞争，从而实现多核的利用，但是也带来一些同步和通信问题，这也是必然会出现的。
Ctypes
CPython的优势就是与C模块的结合，因此可以借助Ctypes调用C的动态库来实现将计算转移，C动态库没有GIL可以实现对多核的利用。
协程
协程也是一个很好的手段，在Python3.4之前没有对协程的支持，存在一些三方库的实现，比如gevent和Tornado。
Python3.4之后就内置了asyncio标准库真正实现了协程这一特性。
9.小结
GIL仍然是Python语言里最困难的技术挑战，GIL问题的并不是编程语言的本身问题，换做其他语言只是将问题转移到了用户层面，相反Python的作者尝试将这种问题转移到解释器给使用者呈现一个优雅的语言。
虽然多核时代的到来暴露了GIL的缺陷，但是Python决策者和社区开发者已经做出了许多其他措施来拥抱多核，无知地诟病GIL是不明智的做法。
如同生产关系要适应生产力的发展一样，抛开历史背景谈机制的优劣，都是有失偏颇的，所以对待GIL要辩证看待。
近期热门文章推荐：
