Python GIL（Global Interpreter Lock）

一、介绍

In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple
native 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 解释器中，同一个进程下开启的多线程，同一时刻只能有一个线程执行，无法利用多核优势

　　首先需要明确的一点是 GIL 并不是 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 介绍

　　GIL 本质就是一把互斥锁，既然是互斥锁，所有互斥锁的本质都一样，都是将并发运行变成串行，以此来控制同一时间内共享数据只能被一个任务所修改，进而保证数据安全。

　　可以肯定的一点是：保护不同的数据的安全，就应该加不同的锁。

　　要想了解 GIL，首先确定一点：每次执行 python 程序，都会产生一个独立的进程。例如 python test.py，python aaa.py，python bbb.py会产生 3 个不同的 python 进程

# test.py内容
import os, time
print(os.getpid())
time.sleep(100)

python3 test.py 会查看到一个进程的pid
在 Windows 下 tasklist | findstr python
在 Linux 下 ps aux |grep python
会发现它们是相同的

验证 python test.py 只会产生一个进程

　　在一个 python 的进程内，不仅有 test.py 的主线程或者由该主线程开启的其他线程，还有解释器开启的垃圾回收等解释器级别的线程，总之，所有线程都运行在这一个进程内，毫无疑问：

　　1、所有数据都是共享的，这其中，代码作为一种数据也是被所有线程共享的（test.py 的所有代码以及 CPython 解释器的所有代码）

　　例如：test.py 定义一个函数 work，在进程内所有线程都能访问到 work 的代码，于是我们可以开启三个线程然后 target 都指向该代码，能访问到意味着就是可以执行。

　　2、所有线程的任务，都需要将任务的代码当做参数传给解释器的代码去执行，即所有的线程要想运行自己的任务，首先需要解决的是能够访问到解释器的代码。

综上：如果多个线程的 target=work，那么执行流程是：

　　多个线程先访问到解释器的代码，即拿到执行权限，然后将 target 的代码交给解释器的代码去执行

　　解释器的代码是所有线程共享的，所以垃圾回收线程也可能访问到解释器的代码而去执行，这就导致了一个问题：对于同一个数据 100，可能线程 1 执行 x=100 的同时，而垃圾回收执行的是回收 100 的操作，解决这种问题没有什么高明的方法，就是加锁处理，如下图的 GIL，保证 python 解释器同一时间只能执行一个任务的代码

三、GIL 和 Lock

　　Python 已经有一个 GIL 来保证同一时间只能有一个线程来执行了，为什么这里还需要 Lock？

　　首先，我们需要达成共识：锁的目的是为了保护共享的数据，同一时间只能有一个线程来修改共享的数据，然后，我们可以得出结论：保护不同的数据就应该加不同的锁。最后，问题就很明朗了，GIL 与 Lock 是两把锁，保护的数据不一样，前者是解释器级别的（当然保护的就是解释器级别的数据，比如垃圾回收的数据），后者是保护用户自己开发的应用程序的数据，很明显 GIL 不负责这件事，只能用户自定义加锁处理，即 Lock

　　GIL 保护的是解释器级别的数据，保护用户自己的数据则需要自己加锁处理，如下图：

分析：

　　1、100 个线程去抢 GIL 锁，即抢执行权限

　　2、肯定有一个线程先抢到 GIL（暂且称为线程 1），然后开始执行，一旦执行就会拿到 lock.acquire()

　　3、极有可能线程 1 还未运行完毕，就有另外一个线程 2 抢到 GIL，然后开始运行，但线程 2 发现互斥锁 Lock 还未被线程 1 释放，于是阻塞，被迫交出执行权限，即释放 GIL

　　4、直到线程 1 重新抢到 GIL，开始从上次暂停的位置继续执行，直到正常释放互斥锁 Lock，然后其他的线程再重复 2 3 4 的过程

四、GIL 与多线程

　　有了 GIL 的存在，同一进程内所有的线程在同一时刻只能有一个执行

　　听到这里，有的人立马质问：进程可以利用多核，但是开销大，而 Python 的多线程开销小，但却无法利用多核优势，也就是说 Python 没用了？所以说，要解决这个问题，我们需要在几个点上达成一致：

　　1、CPU 到底是用来做计算的，还是用来做 I/O 的？

　　2、多 CPU，意味着可以有多个核并行完成计算，所以多核提升的是计算性能

　　3、每个 CPU 一旦遇到 I/O 阻塞，仍然需要等待，所以多核对 I/O 操作用处并不大

　　一个工人相当于 CPU ，此时计算相当于工人在干活，I/O 阻塞相当于为工人干活提供所需原材料的过程，工人干活的过程中如果没有原材料了，则工人干活的过程需要停止，直到等待原材料的到来。

　　如果你的工厂干的大多数任务都要有准备原材料的过程（I/O 密集型），那么你有再多的工人，意义也不大，还不如一个人，在等材料的过程中让工人去干别的活，反过来讲，如果你的工厂原材料都齐全，那当然是工人越多，效率越高

结论：

　　对计算来说，CPU 越多越好，但是对于 I/O 来说，再多的 CPU 也没用，当然对运行一个程序来说，随着 CPU 的增多执行效率肯定会有所提高（不管提高幅度多大，总会有所提高），这是因为一个程序基本上不会是纯计算或者纯 I/O，所以我们只能相对的去看一个程序到底是计算密集型还是 I/O 密集型，从而进一步分析 Python 的多线程到底有无用武之地

假设我们有四个任务需要处理，处理方式肯定是需要并发的效果，解决方案可以是：

　　方案一：开启四个进程

　　方案二：一个进程下，开启四个线程

单核情况下，分析结果：

　　如果四个任务是计算密集型，没有多核来并行计算，方案一徒增了创建进程的开销。方案二更优。如果四个任务是 I/O 密集型，方案一创建进程的开销大，且进程的切换速度远不如线程。方案二更优

多核情况下，分析结果：

　　如果四个任务是计算密集型，多核意味着并行计算，在 Python 中一个进程中同一时刻只有一个线程执行，比不上多核。方案一更优。如果四个任务是 I/O 密集型，再多的核也解决不了I/O问题，方案二更优。

结论：现在的计算机基本上都是多核，Python 对于计算密集型的任务开多线程的效率并不能带来多大性能上的提升，甚至不如串行(没有大量切换)，但是，对于 I/O 密集型的任务效率还是有显著提升的。