深入浅出Python GIL锁（全局解释器锁）

GIL：Global Interpreter Lock

引入GIL

在Linux系统中，有一个htop命令，可以查看当前CPU的使用情况。
如果是一核的CPU显示是这样的：

image.png

双核如下（左上角）：

image.png

1，2表示当前虚拟机的CPU核数是两核（双核），百分比显示的是占用的资源率。
双核的含义就是同一时间可以做两件事情。
如果是单核，一定是并发。

如果是双核，实际上是可能出现简单的并行。CPU的核数越多，可以同时执行的事情越多。
当前资源占用率比较小，然后执行以下当前的这个文件：

image.png

运行结果如下：

image.png

这是一个单线程死循环，可以看到单线程已经占满了一个核。
用Ctrl+C结束程序：

image.png

再看CPU资源占用率：

image.png

又降下来了。
如果开两个终端都运行这一份代码：

image.png

当前运行了两个进程，资源占用率占满了。
再运行一份新的程序，代码如下：

image.png

上半部分是子线程死循环，下半部分是主线程死循环。
然后运行这个程序，那么当前是一个进程，这个进程里有两个线程。
当前的CPU资源占用率如下：

image.png

如果把上述的两个线程改为两个进程，代码如下：

image.png

运行这个程序：

image.png

所以由此可见，在Python中真正能够做到并发的只有多进程，多线程的并发是“假的”。
这就是因为Python里面有GIL。
GIL保证了当程序有多线程的时候，同一时间只有一个线程在执行。
GIL这个问题并不是Python本身的问题，而是Python解释器的问题，而且只有Cpython解释器有这个问题。

多线程比单线程要快吗

多线程是比单线程要快，虽然Cpython有GIL锁，但是它会在适合的时间转换给其他的线程去执行。
比如有三个网络程序要发送数据并接收数据，接收要等待的时间是五分钟，如果是单线程，三个程序全部执行完大约需要15分钟。如果是多线程，在发送完第一个程序的数据后，因为需要等待五分钟，系统就会把这个程序暂时挂起，然后发送第二个程序的数据，发送完把第二个程序也挂起，再发送第三个程序的数据，这样过了五分钟之后，差不多三个程序的数据都接收到了，总的执行时间在五分钟左右，比单线程节省了十分钟。所以多线程在一些网络程序上面是比单线程要快的。

GIL效率低下体现在什么方面

有两种类型的程序，一个是计算密集型程序，一个是IO密集型程序。
计算密集型是指，比如下面的伪代码：

import threading

# 子线程
def test():
    while True:
        # 计算1到1千万之间每一个数的立方和


t1 = threading.Thread(target = test)
t1.start()

# 主线程
while True:
    # 计算1到1千亿之间每个数的立方和

因为GIL的原因，这个程序的两个线程同一时间只会有一个在执行，那么这个时候，即使CPU是四核的，也发挥不了作用。计算密集型，也就是程序没有延时。没有time也没有sleep。
真正可以用多线程去执行程序的情况是，程序是IO密集型程序的。也就是程序涉及读写，这时候就会产生等待。
所以如果是计算密集型程序，要用进程，如果是IO密集型要用线程。

怎么克服GIL所带来的问题

1.换一个解释器，因为只有Cpython有GIL锁，其他语言类型的解释器都没有GIL。
2.用其他的语言来实现功能
因为Python可以直接调用其他类型的语言，所以多线程部分的代码可以用其他语言实现。
3.更换更高版本的Python解释器，从3.2版本开始，Python开始对解释进行优化，虽然不能完全避开GIL，但是优化了总比优化前好。
4.Python程序如果是计算密集型的，或者是需要使用多核CPU的程序，可以使用多进程替代多线程(增强硬件然后使用多进程)。