python全局解释器锁（GIL）
文章做者：卢钧轶(cenalulu) 本文原文地址：http://cenalulu.github.io/python/gil-in-python/ ，对文章作了适当的修改，加入了一些本身的理解。python
CPU-bound(计算密集型) 和I/O bound(I/O密集型)
计算密集型任务(CPU-bound) 的特色是要进行大量的计算，占据着主要的任务，消耗CPU资源，一直处于满负荷状态。好比复杂的加减乘除、计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也能够用多任务完成，可是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，因此，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。linux
计算密集型任务因为主要消耗CPU资源，所以，代码运行效率相当重要。Python这样的脚本语言运行效率很低，彻底不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。git
IO密集型任务(I/O bound)的特色是指磁盘IO、网络IO占主要的任务，CPU消耗不多，任务的大部分时间都在等待IO操做完成（由于IO的速度远远低于CPU和内存的速度）。github
IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间不多，所以，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，彻底没法提高运行效率。算法
对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，好比请求网页、读写文件等。固然咱们在Python中能够利用sleep达到IO密集型任务的目的。编程
对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。缓存
什么是GIL（Global Interpreter Lock）
首先须要明确的一点是GIL并非Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。就比如C++是一套语言（语法）标准，可是能够用不一样的编译器来编译成可执行代码。有名的编译器例如GCC，INTEL C++，Visual C++等。Python也同样，一样一段代码能够经过CPython，PyPy，Psyco等不一样的Python执行环境来执行。像其中的JPython就没有GIL。然而由于CPython是大部分环境下默认的Python执行环境。因此在不少人的概念里CPython就是Python，也就想固然的把GIL归结为Python语言的缺陷。因此这里要先明确一点：GIL并非Python的特性，Python彻底能够不依赖于GIL。网络
1. 设置GIL
2. 切换到一个线程去运行
3. 运行：
a. 指定数量的字节码指令，或者
b. 线程主动让出控制（能够调用time.sleep(0)）
4. 把线程设置为睡眠状态
5. 解锁GIL
6. 再次重复以上全部步骤
为何会有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设计原理及缺陷
基于pcode数量的调度方式
按照Python社区的想法，操做系统自己的线程调度已经很是成熟稳定了，没有必要本身搞一套。因此Python的线程就是C语言的一个pthread，并经过操做系统调度算法进行调度（例如linux是CFS）。为了让各个线程可以平均利用CPU时间，python会计算当前已执行的微代码数量，达到必定阈值后就强制释放GIL。而这时也会触发一次操做系统的线程调度（固然是否真正进行上下文切换由操做系统自主决定）。
任何Python线程执行前，必须先得到GIL锁，而后，每执行100条字节码，解释器就自动释放GIL锁，让别的线程有机会执行。这个GIL全局锁实际上把全部线程的执行代码都给上了锁，因此，多线程在Python中只能交替执行，即便100个线程跑在100核CPU上，也只能用到1个核。
伪代码
while True:
acquire GIL
for i in 100:
do something
release GIL
# Give Operating System a chance to do thread scheduling
这种模式在只有一个CPU核心的状况下毫无问题。任何一个线程被唤起时都能成功得到到GIL（由于只有释放了GIL才会引起线程调度）。但当CPU有多个核心的时候，问题就来了。从伪代码能够看到，从release GIL到acquire GIL之间几乎是没有间隙的。因此当其余在其余核心上的线程被唤醒时，大部分状况下主线程已经又再一次获取到GIL了。这个时候被唤醒执行的线程只能白白的浪费CPU时间，看着另外一个线程拿着GIL欢快的执行着。而后达到切换时间后进入待调度状态，再被唤醒，再等待，以此往复恶性循环。
PS：固然这种实现方式是原始而丑陋的，Python的每一个版本中也在逐渐改进GIL和线程调度之间的互动关系。例如先尝试持有GIL在作线程上下文切换，在IO等待时释放GIL等尝试。可是没法改变的是GIL的存在使得操做系统线程调度的这个原本就昂贵的操做变得更奢侈了。
关于GIL影响的扩展阅读
为了直观的理解GIL对于多线程带来的性能影响，这里直接借用的一张测试结果图（见下图）。图中表示的是两个线程在双核CPU上得执行状况。两个线程均为CPU密集型运算线程。绿色部分表示该线程在运行，且在执行有用的计算，红色部分为线程被调度唤醒，可是没法获取GIL致使没法进行有效运算等待的时间。
由图可见，GIL的存在致使多线程没法很好的当即多核CPU的并发处理能力。
那么Python的IO密集型线程可否从多线程中受益呢？咱们来看下面这张测试结果。颜色表明的含义和上图一致。白色部分表示IO线程处于等待。可见，当IO线程收到数据包引发终端切换后，仍然因为一个CPU密集型线程的存在，致使没法获取GIL锁，从而进行无尽的循环等待。
简单的总结下就是：Python的多线程在多核CPU上，只对于IO密集型计算产生正面效果；而当有至少有一个CPU密集型线程存在，那么多线程效率会因为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的存在，只有IO Bound场景下得多线程会获得较好的性能
- 若是对并行计算性能较高的程序能够考虑把核心部分也成C模块，或者索性用其余语言实现
- GIL在较长一段时间内将会继续存在，可是会不断对其进行改进