老卫带你学---python的GIL锁

老卫带你学—python的GIL锁

GIL是什么

首先需要明确的一点是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

那么CPython实现中的GIL又是什么呢？GIL全称Global Interpreter Lock.

为什么会有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，python只有一个GIL，运行python时，就要拿到这个锁才能执行，在遇到I/O 操作时会释放这把锁。
在Python2中，如果是纯计算的程序，没有 I/O 操作，解释器会每隔100次操作就释放这把锁，让别的线程有机会 执行（这个次数可以通sys.setcheckinterval来调整）同一时间只会有一个获得GIL线程在跑，其他线程都处于等待状态

• 1、如果是CPU密集型代码（循环、计算等），由于计算工作量多和大，计算很快就会达到100，然后触发GIL的释放与在竞争，多个线程来回切换损耗资源，所以在多线程遇到CPU密集型代码时，单线程会比多线程的快。
• 2、如果是I\O密集型代码（文件处理、网络爬虫），开启多线程实际上是并发（不是并行），IO操作会进行IO等待，线程A等待时，自动切换到线程B，这样就提升了效率，比单线程快很多

而在python3.x中，GIL不使用ticks计数，改为使用计时器（执行时间达到阈值后，当前线程释放GIL），这样对CPU密集型程序更加友好，但依然没有解决GIL导致的同一时间只能执行一个线程的问题，所以效率依然不尽如人意。

多核多线程比单核多线程更差，原因是单核下多线程，每次释放GIL，唤醒的那个线程都能获取到GIL锁，所以能够无缝执行，但多核下，CPU0释放GIL后，其他CPU上的线程都会进行竞争，但GIL可能会马上又被CPU0拿到，导致其他几个CPU上被唤醒后的线程会醒着等待到切换时间后又进入待调度状态，这样会造成线程颠簸(thrashing)，导致效率更低

“python下想要充分利用多核CPU，就用多进程”，原因是什么呢？

原因是：每个进程有各自独立的GIL，互不干扰，这样就可以真正意义上的并行执行，（多线程并不是真正意义上的并行执行，只能算并发执行）所以在python中，多进程的执行效率优于多线程(仅仅针对多核CPU而言)。

由于现实生活中运行的总进程数量总是多于 CPU核心数量！因此，严格来说并没有真正意义上的并行。现在运行的程序都是轮询调度产生的并行假象，所以如何根据实际情况选择多进程或是多线程。

总结

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

因为GIL的存在，只有IO密集型场景下的多线程会得到较好的性能，而在CPU密集型（计算密集型）或者高并发场景下，使用多进程效率会更快。
GIL在较长一段时间内将会继续存在，但是会不断对其进行改进。
GIL的全称是全局解释器锁， 也就是一个解释器一个锁，解释器也就是python.exe可执行文件，GIL的目的是确保每个进程中只有一个线程运行，所以多个进程之间是不会互相影响的，多进程确实可以用来削弱GIL的负面影响，但是对于IO密集型操作事务，多进程理论上也会比多线程快一点，但是因为多进程消耗的资源也比多线程大很多，所以说你只有少数的任务并发，你用多进程没有问题，但是并发任务多的情况而且是IO密集型操作，用多线程就比多进程好的多，毕竟多线程占用资源少，比多进程更加便于管理，多进程的管理比多线程要复杂而且不稳定。