Python－GIL详解

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击人工智能教程

GIL是什么

首先需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器（CPython）时所引入的一个概念。这里要明确一点：GIL并不是Python的特性，Python完全可以不依赖于GIL。

那么CPython实现中的GIL又是什么呢？GIL全称Global Interpreter Lock，为了避免误导，我们还是来看一下官方给出的解释：

In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)

好吧，是不是看上去很糟糕？一个防止多线程并发执行机器码的一个Mutex，乍一看就是个BUG般存在的全局锁嘛！别急，我们下面慢慢的分析。

为什么会有GIL

由于物理上的限制，各CPU厂商在核心频率上的比赛已经被多核所取代。为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难，即使在CPU内部的Cache也不例外。为了有效解决多份缓存之间的数据同步问题，各厂商花费了不少心思，也不可避免的带来了一定的性能损失。

Python当然也逃不开，为了利用多核，Python开始支持多线程。而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。于是就有了GIL这把超级大锁，而当越来越多的代码库开发者接受了这种设定后，他们开始大量依赖这种特性（即默认Python内部对象是Thread-Safe的，无需在实现时考虑额外的内存锁和同步操作）。

慢慢的这种实现方式被发现是恼人且低效的。但当大家试图去拆分和去除GIL的时候，发现大量库代码开发者已经重度依赖GIL而非常难以去除了。有多难？做个类比，像MySQL这样的“小项目”为了把Buffer Pool Mutex这把大锁拆分成各个小锁也花了从5.5到5.6再到5.7多个大版本为期近5年的时间，并且仍在继续。MySQL这个背后有公司支持且有固定开发团队的产品尚且走的如此艰难，那又更何况Python这样核心开发和代码贡献者高度社区化的团队呢？

所以简单的说GIL的存在更多的是历史原因。如果推倒重来，多线程的问题依然还是要面对，但是至少会比目前GIL这种方式会更优雅。

GIL的影响

从上文的介绍和官方的定义来看，GIL无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响，甚至就几乎等于Python是个单线程的程序。

为了直观的理解GIL对于多线程带来的性能影响，这里直接借用一张测试结果图（见下图）。图中表示的是两个线程在双核CPU上的执行情况。两个线程均为CPU密集型运算线程。绿色部分表示该线程在运行，且在执行有用的计算；红色部分为线程被调度唤醒，但是无法获取GIL导致无法进行有效运算等待的时间。

由图可见，GIL的存在导致多线程无法很好的利用多核CPU的并发处理能力。

那么Python的IO密集型线程能否从多线程中受益呢？我们来看下面这张测试结果。颜色代表的含义和上图一致。白色部分表示IO线程处于等待。可见，当IO线程收到数据包引起终端切换后，仍然由于一个CPU密集型线程的存在，导致无法获取GIL锁，从而进行无尽的循环等待。

简单的总结下就是：Python的多线程在多核CPU上，只对于IO密集型计算产生正面效果；而当至少有一个CPU密集型线程存在，那么多线程效率会由于GIL而大幅下降。

如何避免受到GIL的影响

说了那么多，如果不说解决方案就仅仅是个科普帖，然并卵。GIL这么烂，有没有办法绕过呢？我们来看看有哪些现成的方案。

用MultiProcess替代Thread

multiprocess库的出现很大程度上是为了弥补thread库因为GIL而低效的缺陷，它完整的复制了一套thread所提供的接口方便迁移，唯一的不同就是它使用了多进程而不是多线程。每个进程有自己的独立的GIL，因此也不会出现进程之间的GIL争抢。

当然multiprocess也不是万能良药，它的引入会增加程序实现时线程间数据通讯和同步的困难。就拿计数器来举例子，如果我们要多个线程累加同一个变量，对于thread来说，申明一个global变量，用thread.Lock的context包裹住，三行就搞定了。而multiprocess由于进程之间无法看到对方的数据，只能通过在主线程申明一个Queue，put再get或者用share memory的方法。这个额外的实现成本使得本来就非常痛苦的多线程程序编码，变得更加痛苦了。

用其他解析器

之前也提到了既然GIL只是CPython的产物，那么用其他解析器是不是更好呢？没错，像JPython和IronPython这样的解析器由于实现语言的特性，他们不需要GIL的帮助。然而由于使用了Java/C#用于解析器实现，他们也失去了利用社区众多C语言模块有用特性的机会，所以这些解析器也因此一直都比较小众。毕竟功能和性能大家在初期都会选择前者，done is better than perfect。

所以没救了么？

当然Python社区也在非常努力的不断改进GIL，甚至是尝试去除GIL，并在各个小版本中有了不少的进步。

总结

Python GIL其实是功能和性能之间权衡后的产物，它有其存在的合理性，也有较难改变的客观因素。从本文的分析中，我们可以做以下一些简单的总结：

• 因为GIL的存在，只有IO密集场景下的多线程会得到较好的性能
• 如果对并行计算性能要求较高的程序可以考虑把核心部分做成C模块，或者索性用其他语言来实现
• GIL在较长一段时间内将会继续存在，但是会不断对其进行改进