Cpython的GIL全局解释器锁

我们要知道一点GIL并不是Python的特性，它是Python解释器Cpython引入的一个概念。就好比C++这门语言，可以用不同的编译器来编译成可执行代码。它的编译器有GCC,INTEL C++，VIsual C++等。Python也一样，同样代码可以通过JPython,PyPy,Cpthon等环境中解释执行。像其中的JPython，就没有GIL。但是Cpython是大部分环境下默认的Python执行环境。所以在很多人的概念里就把CPython当成了Python,也就想当然的把GIL归结为Python语言的缺陷。所以这里要先明确一点：GIL并不是Python的特性，Python完全可以不依赖GIL。

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的内存管理不是线程安全的。（然而，由于GIL的存在，其他的特性已经发展到依赖于它所执行的保证。）我们可得出结论在CPython的环境下，即使在多核的情况下，同一个进程启动多个线程，只能执行一个线程。无法利用多核的一个优势。

    因为Guido van Rossum创造python在写Cpython解释器的时候，也没有想到他的语言会有一天会在多核的电脑上跑。多核CPU在20世纪90年代还属于科幻的乐西。线程安全是在多线程并发的环境下能够保证多个线程同时执行时程序 依旧准确运行，我们知道在Python中有一个垃圾回收机制，谅把他当作一个线程。我们让一些线程执行任务的进修，垃圾回收线程也会跟着并发执行起来。为了不会导致一些线程资源被随意回收，所以就要加锁处理，加锁可以保证线程与线程之意有序安全的运行。一个全局锁搞定多络程安全在龟叔的那个时代应该是最简单精细的设计了吧。

    因为Cypthon的内存管理不是安全的，同个进程内的多个线程，同一时间内要抢这个解释器这个解释器有一把锁，一次只能一个线程抢到执行权限。

    GIL本质就是一把互斥锁，是夹在解释器身上的，同一进程内的所有线程都需要先抢到GIL锁，才能执行解释器代码。

    GIL的优点：保证Cpython解释器内存管理的线程安全

    GIL的缺点：同一进程内所有的线程同一时刻只能有一个执行。也就是说Cpython解释器的多线程无法实现并行。

    所以有些同学就会想到Cpthon中已经有一个GIL来保证同一时间只能有一个线程来执行，为什么还需要Lock?

    首先我们知道锁的目的是保护其享数据的，同一个时间只能有一个线程来修改其享的数据。那我们要保护不同的数据是不是应该就要用不同类型的锁呢。很明显GIL和Lock是两种锁，保护的数据是不一样的，GIL是解释器级级别的，，当然是保护解释器级别的数据。就如之前所说的垃圾回收数据。而lock是保护程序员自己开发的应用程序数据。很明显GIL不会负责这个事情，只能程序员自己去加锁处理。付一张图来参考理解：