Python GIL

编程语言类型

解释型语言

Python、java 都是解释型语言

源代码不是直接翻译成机器语言，而是先翻译成中间代码，再由解释器对中间代码进行解释运行。程序不需要编译，在运行时才翻译成机器语言，每执行一次都要翻译一次，所以效率比较低。

编译型语言

C 和 C++ 都是编译型语言

程序在执行之前需要一个专门编译的过程，把程序编译成为机器语言的文件，运行时不需要重新翻译，直接使用编译结果，所以效率较高。

利与弊

编译型语言跨平台性质要差些，依赖编译器，编译器把程序编译成机器语言（二进制文件），不同的操作系统计算识别的二进制文件是不同的，所以程序经行移植后（比如从 win 到 linux）需要重新编译。但效率较高

解释型语言跨平台性质好，例如java语言，java程序首先通过编译器编译成class文件，如果在windows平台上运行，则通过windows平台上的java虚拟机（VM）进行解释。如果运行在linux平台上，则通过linux平台上的java虚拟机进行解释执行。只要有专门的翻译器即可，但效率较低

密集型

I/O 密集型

指磁盘 I/O、网络 I/O 占主要的任务（比如请求网页、读写文件等），CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为 I/O 的速度远远低于CPU和内存的速度）。

I/O 密集型任务执行期间，99%的时间都花在 I/O 上，花在CPU上的时间很少，因此把 C 语言换成 Python 也无法提高效率，反而 Python 简洁的代码更有优势

CPU 密集型

要进行大量的计算，占据着主要的任务，消耗CPU资源，一直处于满负荷状态（比如复杂的加减乘除、计算圆周率、对视频进行高清解码等等）。全靠CPU的运算能力。

计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。

扩展：（ Python 运行其他语言的代码还是很方便的）

在 python 中调用 C 语言代码

// 比如有一段 C 语言代码如下：文件名为 addr.c
#include <stdio.h>

int add_int(int, int);
float add_float(float, float);

int add_int(int num1, int num2){
	return num1 + num2;
}

float add_float(float num1, float num2){
	return num1 + num2;
}

#For Linux
$ gcc -shared -Wl,-soname,adder -o addr.so -fPIC addr.c

// python 代码
from ctypes import *

#load the shared object file
adder = CDLL('./adder.so')

#Find sum of integers
res_int = adder.add_int(4,5)
print "Sum of 4 and 5 = " + str(res_int)

#Find sum of floats
a = c_float(5.5)
b = c_float(4.1)

add_float = adder.add_float
add_float.restype = c_float
print "Sum of 5.5 and 4.1 = ", str(add_float(a, b))

GIL

GIL 是什么

GIL：Global Interpreter Lock 全局解释锁

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

Python 代码的执行由 Python 虚拟机(也叫解释器主循环，CPython版本)来控制，Python 在设计之初就考虑到要在解释器的主循环中，同时只有一个线程在执行，即在任意时刻，只有一个线程在解释器中运行。对Python 虚拟机的访问由全局解释器锁（GIL）来控制，正是这个锁能保证同一时刻只有一个线程在运行。

测试代码

from threading import Thread
import time


def my_counter():
    i = 0
    for _ in range(100000000):
        i = i + 1
    return True

# Total time: 6.979069471359253
def main():
    start_time = time.time()
    for tid in range(2):
        my_counter()
    end_time = time.time()
    print("single Total time: {}".format(end_time - start_time))

# Total time: 7.563473463058472
def main1():
    thread_array = []
    start_time = time.time()
    for tid in range(2):
        t = Thread(target=my_counter)
        t.start()
        thread_array.append(t)
    for i in range(2):
        thread_array[i].join()
    end_time = time.time()
    print("more Total time: {}".format(end_time - start_time))

if __name__ == '__main__':
    main()
    main1()
# 多线程比单线程还慢。。。

在多线程环境中，Python 虚拟机按以下方式执行：

1. 设置 GIL
2. 切换到一个线程去运行
3. 运行：两种机制
   1. 指定数量的字节码指令
   2. 固定时间 15ms 线程主动让出控制
4. 把线程设置为睡眠态
5. 解锁 GIL
6. 再次重复以上步骤

在调用外部代码（如C/C++扩展函数）的时候，GIL 将会被锁定，直到这个函数结束为止（由于在这期间没有Python 的字节码被运行，所以不会做线程切换）。

为什么有 GIL

阅读多篇博客，GIL 就相当于一个粗粒度的大锁，将大部分资源都锁住，所以对于线程之间的数据完整性和状态同步有很不错的效果，但现在的多核性能完全发挥不出来。

由于物理上得限制，各CPU厂商在核心频率上的比赛已经被多核所取代。为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难。即使在CPU内部的Cache也不例外，为了有效解决多份缓存之间的数据同步时各厂商花费了不少心思，也不可避免的带来了一定的性能损失。

Python当然也逃不开，为了利用多核，Python开始支持多线程。而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。 于是有了GIL这把超级大锁，而当越来越多的代码库开发者接受了这种设定后，他们开始大量依赖这种特性（即默认python内部对象是thread-safe的，无需在实现时考虑额外的内存锁和同步操作）。

慢慢的这种实现方式被发现是蛋疼且低效的。但当大家试图去拆分和去除GIL的时候，发现大量库代码开发者已经重度依赖GIL而非常难以去除了。

解决方案

换解释器

之前也提到了既然GIL只是CPython的产物，那么其他解析器是不是更好呢？没错，像JPython和IronPython这样的解析器由于实现语言的特性，他们不需要GIL的帮助。然而由于用了Java/C#用于解析器实现，他们也失去了利用社区众多C语言模块有用特性的机会。所以这些解析器也因此一直都比较小众。毕竟功能和性能大家在初期都会选择前者。

用multiprocess替代Thread

multiprocess库的出现很大程度上是为了弥补thread库因为GIL而低效的缺陷。它完整的复制了一套thread所提供的接口方便迁移。唯一的不同就是它使用了多进程而不是多线程。每个进程有自己的独立的GIL，因此也不会出现进程之间的GIL争抢。（使用多进程代替要考虑到这些资源是否值得）

利用 ctypes 绕过 GIL

ctypes 是一个用于Python的外部函数库。它提供C兼容的数据类型，并允许在DLL或共享库中调用函数。它可以用来将这些库封装在纯Python中。所要做的只是用 ctypes 写 python 代码即可。而且，ctypes 会在调用 C 函数前释放 GIL。（详细可自行了解 ctypes）

推荐博文：https://www.cnblogs.com/SuKiWX/p/8804974.html