GIL锁

GIL锁

何为 GIL 锁？

全局解释器锁（英語：Global Interpreter Lock，缩写GIL），是计算机程序设计语言解释器用于同步线程的一种机制，它使得任何时刻仅有一个线程在执行。 即便在多核心处理器上，使用GIL 的解释器也只允许同一时间执行一个线程。 常见的使用GIL 的解释器有CPython与Ruby MRI。

在Python多线程下，每个线程的执行方式：

1.获取GIL
2.执行代码直到sleep或者是python虚拟机将其挂起。
3.释放GIL

GIL存在的意义？

因为python的线程是调用操作系统的原生线程，这个原生线程就是C语言写的原生线程。因为python是用C写的，启动的时候就是调用的C语言的接口。因为启动的C语言的远程线程，那它要调这个线程去执行任务就必须知道上下文，所以python要去调C语言的接口的线程，必须要把这个上限问关系传给python，那就变成了一个我在加减的时候要让程序串行才能一次计算。就是先让线程1，再让线程2…

每个线程在执行的过程中，python解释器是控制不了的，因为是调的C语言的接口，超出了python的控制范围，python的控制范围是只在python解释器这一层，所以python控制不了C接口，它只能等结果。所以它不能控制让哪个线程先执行，因为是一块调用的，只要一执行，就是等结果，这个时候4个线程独自执行，所以结果就不一定正确了。有了GIL，就可以在同一时间只有一个线程能够工作。虽然这4个线程都启动了，但是同一时间我只能让一个线程拿到这个数据。其他的几个都干等。python启动的4个线程确确实实落到了这4个cpu上，但是为了避免出错。这也是Cpython的一个缺陷，其他语言没有，仅仅只是Cpython有。

线程互斥锁和GIL的区别

1.线程互斥锁是Python代码层面的锁，解决Python程序中多线程共享资源的问题(线程数据共共享，当各个线程访问数据资源时会出现竞争状态，造成数据混乱)；

2.GIL是Python解释层面的锁，解决解释器中多个线程的竞争资源问题（多个子线程在系统资源竞争是，都在等待对象某个部分资源解除占用状态，结果谁也不愿意先解锁，然后互相等着，程序无法执行下去）。

GIL锁关系图

GIL(全局解释器锁)是加在python解释器里面的，效果如图：

如上图，为什么GIL锁要加在python解释器这一层，而却不加在其他地方？

因为你python调用的所有线程都是原生线程。原生线程是通过C语言提供原生接口，相当于C语言的一个函数。你一调它，你就控制不了了它了，就必须等它给你返回结果。只要已通过python虚拟机，再往下就不受python控制了，就是C语言自己控制了。你加在python虚拟机以下，你是加不上去的。同一时间，只有一个线程穿过这个锁去真正执行。其他的线程，只能在python虚拟机这边等待。

总结

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

GIL对程序有啥影响
1.Python中同一时刻有且只有一个线程会执行；2.Python中的多个线程由于GIL锁的存在无法利用多核CPU；3.Python中的多线程不适合计算机密集型的程序；4.如果程序需要大量的计算，利用多核CPU资源，可以使用多进程来解决。GIL 的存在使程序无法充分利用CPU进行运算，那么它真的一无是处么？ 再进一步分析，程序分为两种，一种是上面提到的计算密集型程序，另一种叫作IO密集型程序。大部分的程序在运行时，都需要大量IO操作，比如网络数据的收发，大文件的读写，这样的程序称为IO密集型程序。IO密集型程序在运行时，需要大量的时间进行等待，那么这时如果IO操作不完成，程序就无法执行后面的操作，导致CPU空闲。那么 GIL 对于这种IO密集型程序会有什么影响？在解释器解释执行任何 Python 代码时，都需要先获得这把锁才行，在遇到 I/O 操作时会释放这把锁。如果是纯计算的程序，没有 I/O 操作，解释器会每隔 100 次操作就释放这把锁，让别的线程有机会执行，提高Python程序的执行效率。

如何改善GIL产生的问题
因为 GIL 锁是解释器层面的锁，无法去除 GIL 锁在执行程序时带来的问题。只能去改善。1.更换更高版本的解释器，比如3.6，从3.2版本开始，据说Python对解释做了优化2.更换解释器，比如JPython，但是由于比较小众，支持的模块较少，导致开发的效率降低3.Python为了解决程序使用多核的问题，使用多进程代替多线程

那么是不是python的多线程就完全没用了呢？

在这里我们进行分类讨论：

1、CPU密集型代码(各种循环处理、计数等等)，在这种情况下，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换当然是需要消耗资源的），所以python下的多线程对CPU密集型代码并不友好。

2、IO密集型代码(文件处理、网络爬虫等)，多线程能够有效提升效率(单线程下有IO操作会进行IO等待，造成不必要的时间浪费，而开启多线程能在线程A等待时，自动切换到线程B，可以不浪费CPU的资源，从而能提升程序执行效率)。所以python的多线程对IO密集型代码比较友好。

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

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

回到最开始的问题：经常我们会听到老手说：“python下想要充分利用多核CPU，就用多进程”，原因是什么呢？

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

所以我们能够得出结论：多核下，想做并行提升效率，比较通用的方法是使用多进程，能够有效提高执行效率