Python编程中Python与GIL互斥锁的关系

这篇文章主要介绍“Python编程中Python与GIL互斥锁的关系”，在日常操作中，相信很多人在Python编程中Python与GIL互斥锁的关系问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Python编程中Python与GIL互斥锁的关系”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

GIL 的起源

Python 第一次发布是在 1991 年，当时的 CPU 都是单核，单核中，多线程主要为了一边做IO，一边做 CPU 计算而设计的，Python 编译器是由 C 语言编写的，因此也叫 CPython，那时候很多编程语言没有自动内存管理的功能，为了实现自动垃圾回收，Python 为每一个对象进行了引用计数，当引用计数为 0 的时候说明该对象可以回收，从而释放内存了，比如：

>>> import sys
>>> data = { &＃39;gzh&＃39;: &＃39;Python七号&＃39;}
>>> var1 = data
>>> sys.getrefcount(data)
3
>>>

这里 data 对象就有 3 个引用， 一个是本身，一个是变量 var1，一个是 getrefcount 函数的参数，如果此时又有一个线程引用了 data，那么引用计数再增加 1，如果某个线程使用了 data 后运行结束，那么引用计数就减少 1，多线程对同一个变量「引用计数」进行修改，就会遇到 race conditions（竞争），为了避免 race conditions，最简单有效的办法就是加一个互斥锁。

如果对每一个对象都加锁，有可能引发另一个问题，就是死锁，而且频繁的获取和释放会导致性能下降，最简单有效的方法就是加一个解释器锁，线程在执行任何字节码时都先获取解释器锁，这就避免了死锁，而且不会有太多的性能消耗。当时 CPU 都是单核，而且这种 GIL 设计简单，并不会影响性能，因此一直沿用至今天。GIL 存在最主要的原因，就是因为 Python 的内存管理不是线程安全的，这就是 GIL 产生并存在的主要缘由。

尝试消除 GIL

CPU 进入多核时代后，可以同时做多个计算任务, GIL 才真正变成问题。在 1999 年，有个叫 Greg Stein 的大佬基于 Python 1.5 版本消除了 GIL，取代代之的是在可变数据结构上加上更细粒度的锁，也提交了补丁用于去除对全局可变对象的依赖，然后在标准测试时表明去除 GIL 后单线程比不去除时慢了近 2 倍，测试的机器还是当时性能最好 Windows 机器。也就是说除去了 GIL 后，你使用 2 个 CPU 才能获取比原来 1 个 CPU 稍微好一点的性能，这种提升明显得不偿失，Greg Stein 的尝试也就失败告终。

Python 之父 Guido van Rossum 也欢迎社区的志愿者去尝试去除 GIL，只要不降低单线程的性能，但他也提到，去掉 GIL 不是一件容易的事。

Python 开发者邮件列表中也偶尔会有去除 GIL 的议题，但是以下需求必须满足：

• 简单。从长远来看该方案必须是可实施、可维护的。

• 并发。去除 GIL 必须能提升多线程的性能。

• 速度。去除 GIL 不能降低单线程的性能。

• 满足 CPython 的特性。该方案必须支持 CPython 的功能，比如 __del__ 和弱引用。

• API 的兼容性。该方案应与所有现有CPython扩展使用的宏在源方面兼容。

• 及时销毁不可达对象，回收内存。

• 有序销毁，比如不可达对象 X 引用了 A，那么应该在销毁 A 之前先销毁 X（有些垃圾回收算法并不能做到这一点）。

有些需求不容易被满足，比如 4，5，7，目前，还没有人满足以上需求的同时去除 GIL 成功的。

积重难返

这些年 Python 实在太火了，很多优秀的库都是基于 CPython 进行编写的，很多都是 90 年代的 C 扩展库，如果要除去 GIL，那么很多基于 GIL 编写的 C 扩展便无法使用，也就是去了 GIL，Python 生态有很多扩展或三方库者无法使用。

还有一个很明显的例子，Python 解释器不止有 CPython，还有用 Java 编写的 Python，.NET 实现的 IronPython，这些解释器完全没有 GIL，可是有多少人为它们编写扩展呢？

Python 之所以如此火爆，与它有着丰富的三方库开箱即用有着很大的关系，积重难返，去除 GIL 很困难。

为什么 Python3 一开始时不去除 GIL

Python3 在最开始时是有机会实现很多新功能，在此过程中，打破了一些现有的 C 扩展，然后需要更新和移植更改以配合 Python 3，这也是 Python3 一开始不被社区所接受的原因。

与 Python2 相比，删除 GIL 将使 Python3 在单线程性能方面更慢，而且很多优秀的扩展将不能再使用，如果真的这样，可以想象 Python3 不可能有未来，最终的结果是 Python3 仍然保持有 GIL。

但 Python3 也为现有的 GIL 带来了重大改进，在 Python 3.2 版本中，确保了计算密集型线程和 I/O 密集型线程并存时， I/O 密集型长期获取不到 GIL 而无法执行的问题，提升了多线程的性能。

到此，关于“Python编程中Python与GIL互斥锁的关系”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注编程笔记网站，小编会继续努力为大家带来更多实用的文章！