Python中的全局解释器锁（GIL）

原文地址：What is the Python Global Interpreter Lock (GIL)
Python全局解释器锁：简单来说，就是只允许Python解释器任意时刻只能有一个线程处于运行状态

1.GIL解决了Python的什么问题？
Python使用引用计数管理内存
举个栗子

>>>import sys
>>> a = []
>>> b = a
>>> sys.getrefcount(a)
3

回到GIL，引用变量在存在两个以上的线程同时增加或减少变量值得情形中，需要保护。如果没有相关机制做到这一点

将会导致未释放的内存泄漏，或者更糟糕的时，当一个对象的引用仍然存在时，致使释放内存出错。，这会使你的Python程序崩溃，或者产生一些奇怪的bugs.

如何解决上面问题：

通过对进程中共享的所有数据结构加锁，这样他们就不会不停的改变，从而保护了引用变量的安全。给每个对象或多个对象添加锁意味着多种锁的存在，这样会导致另外一个问题----Deadlocks(死锁，如果超过一把锁，可能会发生死锁），另一个副作用是由于重复获取和释放锁会导致性能下降。

GIL是解释器上的一个单锁，它为任何需要获取解释器锁的Python程序的执行制定了一个规则。因为是单锁，所以不存在死锁问题，也不会有太多的性能开销。最关键的是，它使得任何 受CPU限制的Python的程序都是单线程的。

GIL虽然被解释器用于其他语言（如Ruby），但并不是解决此问题的唯一方法。 有些语言通过使用除引用计数之外的方法（例如垃圾收集）来避免GIL对线程安全内存管理的要求。

另一方面，这意味着这些语言通常需要通过添加其他性能提升功能（如JIT编译器）来弥补GIL单线程性能优势的损失。

 

2.为什么选择GIL作为解决方案？

事实上，GIL的设计是让Python变得如此流行的一个重要原因。

Python诞生的时候，那个时候的操作系统并没有线程的概念，Python的目的就是易用，加速开发，这样的设计受到很多人的欢迎，越来越多的开发者开始使用Python。

Python的许多使用的特征都是由已存在的C语言库扩展而写的，为了防止不一致的更改，这些C的扩展需要GIL提供的线程安全内存管理。GIL在Python中很容易实现，可以提高对于只需要一个锁管理的单线程程序的性能。非线程安全的C库变得更容易集成。 这些C扩展成为不同社区容易采用Python的原因之一。

正如您所看到的，GIL是一个实用的解决方案，可以解决CPython开发人员在Python生命中早期遇到的一个难题。

 

3.多线程Python程序的影响

当你关注一个典型的Python程序时（或者其他任何电脑程序），那些性能上受CPU限制的和受I/O限制的程序存在差异。受CPU限制的程序在执行数学计算（如矩阵乘法），搜索，图像处理等程序时，会致使CPU的利用接近极限。而受I/O限制的程序仅仅需要等待来自用户、文件、数据库、网络的输入输出。有时候由于信息源在输入输出的时候需要进行一些处理，程序可能会长时间等待直到等到它需要的数据。

下面我们来看一个简单的受CPU限制的程序：

#single_threaded.py
import time
from threading import Thread

COUNT = 50000000

def countdown(n):
    while n>0:
        n -= 1

start = time.time()
countdown(COUNT)
end = time.time()

print('Time taken in seconds ---',end-start)


'Time taken in seconds -', 2.297261953353882

现在更改一下代码使用两个并行线程：

# multi_threaded.py
import time
from threading import Thread

COUNT = 50000000

def countdown(n):
    while n >0:
        n -= 1

t1 = Thread(target=countdown,args = (COUNT//2,))
t2 = Thread(target=countdown,args = (COUNT//2,))

start = time.time()
t1.start()
t2.start()
t1.join()
t2.join()
end = time.time()

print('Time taken in seconds ---',end-start)

'Time taken in seconds -', 2.4209160804748535

可以看到，两个版本所完成任务所花的时间差不多，在第二个版本（multi_threaded）GIL阻止了受CPU限制的线程并发

GIL对于I/O多线程程序的性能没有多大影响，因为在等待I/O的数据时，锁可以在线程之间共享。

但对于一个完全受CPU限制的程序，例如图像处理程序的线程，由于锁的原因，不仅会变成单线程，还会看到执行时间增长，跟上面的例子一样。导致增长的原因是获取和释放锁增加了开销。

 

4.为什么GIL还没移除？

Python开发者听到了太多关于GIL为什么不移除的抱怨，但Python作为种流行的语言，不能随便做出类似移除GIL这样的重大改变，会导致很多兼容性问题。

过去，也有很多开发者和研究者多次尝试想移除GIL，但是这样会打破现有的C扩展，这些扩展很大程度上依赖于GIL提供的解决方案。当然，也有其他方案解决这个问题，只是这些方案中会有一些会致使单线程和受I/O限制的多线程的性能下降，y一些会很难实施，毕竟，我们都不希望新版本的Python程序比现有的程序更慢，对吧？

看Python之父在文章 It isn't Easy to Remove the GIL 提出了他的看法

 

5.为什么Python3中不移除GIL？

Python3是有机会集成很多scratch的特征以及摒弃一些在Python3中使用需要更新和导入的C扩展。这也是早期的Python3版本在社区中难以流行起来的原因。

为什么GIL冰没有被删除？

删除GIL会使Python3在单线程的性能上不如Python2，GIL的单线程性能你无法争论，结果就是Python3中依然有GIL

相反，Python3给GIL带来了一个重要的改进。

我们讨论的是GIL对仅受CPU限制的和仅受I/O限制的多线程程序的影响，那么如果程序的一部分是I/O受限，一部分是CPU受限的呢？

在这样的程序中，已知Python的GIL会使I / O绑定的线程匮乏，因为它们没有机会从CPU绑定的线程中获取GIL。

这是因为Python内置的一种机制迫使线程在连续使用的固定间隔后释放GIL，并且如果没有其他人获得GIL，则相同的线程可以继续使用它。

这种机制的问题在于，大多数情况下，CPU绑定线程会在其他线程获取GIL之前重新获取GIL。这个问题在2009年由Antoine Pitrou在Python 3.2中得到修复，他添加了一种机制（）以查看被删除的其他线程的GIL获取请求数，并且在其他线程有机会运行之前不允许当前线程重新获取GIL。

6.如何处理GIL？

如果GIL给你制造了麻烦，你可以尝试下面一些方法：

多进程 vs 多线程：

如果你不使用线程而是使用多个进程，那么多进程更合适。每个Python进程会得到自己的Python解释器和内存空间，GIL不会成为麻烦。Python有多进程处理模块可以让我们很轻松的创建进程：

例如

from multiprocessing import Pool
import time

COUNT = 50000000
def countdown(n):
    while n > 0:
        n -= 1

if __name__ == "__main__":
    pool = Pool(processes = 2)
    start = time.time()
    r1 = pool.apply_async(countdown,[COUNT//2])
    r2 = pool.apply_async(countdown,[COUNT//2])
    pool.close()
    pool.join()
    end = time.time()
    print('Time taken in seconds ---',end-start)

'Time taken in seconds ---', 1.7674751281738281

对比与多线程的版本，这个性能有很大的提升。

至于时间为什么没有下降到一半，是因为多进程管理具有自己的开销。多进程的开销比多线程的开销大，这可能会成为缩放瓶颈

替代Python解释器：

Python有很多的解释器工具。CPython,Jython,IronPython以及PyPy，分别由C，Java，c#，和Python写的。GIL仅仅存在于最原始的Python实现版本CPython.所以，你的程序及其库可以通过其他解释器实现，可以尝试一下它们。

等：

虽然许多Python用户利用了GIL的单线程性能优势。多线程程序员不必烦恼，因为Python社区中一些最聪明的人正在努力从CPython中删除GIL。 一种这样的尝试被称为Gilectomy。

Python GIL通常被认为是一个神秘而困难的话题。 但请记住，作为Pythonista，如果您正在编写C扩展或者在程序中使用CPU绑定的多线程，则通常只会受到它的影响。