熟悉Python的人对GIL肯定都不陌生, 其全称是全局解释器锁(Global Interpreter Lock)。但是，很多人都误以为GIL是python的特性，所以，首先需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。而其他的实现版本如JPython就没有GIL。然而因为CPython是大部分环境下默认的Python执行环境。所以在很多人的概念里CPython就是Python，也就想当然的把GIL归结为Python语言的缺陷。所以这里要先明确一点：GIL并不是Python的特性，Python完全可以不依赖于GIL
那么CPython实现中的GIL又是什么呢？官方给出的解释：
In CPython, the global interpreter lock, or GIL, is a mutex that protects access to Python objects, preventing multiple 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.)
即原因是在CPython中的线程实际是操作系统的原生线程,而CPython的内存管理不是线程安全的
，于是使用GIL这把大锁锁住其他线程,保证同一时刻只有一个线程可以解释执行字节码。
GIL机制：
按照Python社区的想法，操作系统本身的线程调度已经非常成熟稳定了，没有必要自己搞一套。所以Python的线程就是C语言的一个pthread，并通过操作系统调度算法进行调度（例如linux是CFS）。为了让各个线程能够平均利用CPU时间，python会计算当前已执行的微代码数量ticks，达到一定阈值后就强制释放。而这时也会触发一次操作系统的线程调度（当然是否真正进行上下文切换由操作系统自主决定）。
Python释放GIL的时机之一:
有一个周期性计数的计数器,不断递减,保证Python线程可以在执行一段时间之后释放GIL
仔细分析就会发现问题,假如在解析执行字节码的过程中当前线程遇到了一个IO操作,却由于等待数据而被阻塞在该IO操作上,而从GIL的设计来看，GIL只能通过当前线程主动释放,其他线程才有可能获取。而当前
线程阻塞在IO操作上时,此时给其他线程运行的机会并没有什么问题,因为GIL只是用来同步线程执行字节码的,并非一般的互斥共享资源的互斥锁。在阻塞操作之前让出GIL,其他线程可以继续执行,而当前线程可以继续执行阻塞型的操作,当该阻塞型的操作完成之后,再次试图获取GIL,继续执行余下的字节码。
由此可以看出,Python释放GIL的第二个时机:
在IO操作等可能会引起阻塞的system call之前,可以暂时释放GIL,但在执行完毕后,必须重新获取GIL
问题：
1.CPU密集型代码(各种循环处理、计数等等)，在这种情况下，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换当然是需要消耗资源的）
2.线程的释放与获取是没有间隙的，单核下没什么问题，多核情况下，当当前master线程释放GIL后，其他核心上的线程被唤醒，而此时大部分情况下当前线程又获取了GIL，而被唤醒的线程只能浪费cpu时间而无法运行，直到达到切换时间，切换为待调度状态，这样会造成线程颠簸(thrashing)，导致效率更低。
因此，3开始做了一些优化，如将基于pcode调度改为分时调度；避免释放GIL的线程再次立即被调度等。
http://www.dabeaz.com/GIL/
http://cyrusin.github.io/2016/04/27/python-gil-implementaion/
https://zhuanlan.zhihu.com/p/20953544
http://cenalulu.github.io/python/gil-in-python/
