Python大胆之举：别了GIL，迎接性能和可扩展性的新时代！

新智元报道

编辑：Lumina

【新智元导读】Python社区正式宣布弃用GIL，与新时代一起迈进高效率的多线程处理。

大喜讯！这么多年过去，Python终于决定放弃GIL，真正拥抱多线程时代了。

不再有GIL！Python团队已正式接受这个提案。祝贺 @colesbury 多年来为删除 GIL 所做的出色努力，并衷心感谢 Python 指导委员会和核心团队为实现这一目标而制定的深思熟虑的计划。

众多码农欢呼雀跃这一改变的到来：

Python 中没有 GIL！ 20 多年来，我在大多数项目中都使用 Python 和 C 作为两种互补的「本地」语言。调用C，释放GIL，做繁重的工作，重新获取GIL，返回Python。我不可能忘的，甚至在梦里我都能重复这一套流程。

看起来一个非常古老的设计理念终于被删除了，对我来说必须使用GIL有点烦人。这让我想起了DOS是怎样工作的，但它更优雅一点。

但也有人对这一改变的情感十分复杂：

我感觉有些奇妙，这么多年我学习的所有关于如何获取GIL的知识都没用了.....

但总体而言，大多数程序员还是希望在Python中取消GIL。

感觉是个巨大的改变，希望一切顺利。

在Python中删除GIL看上去真是件大喜事！但，GIL到底是个啥？

一位网友也发出了同样的疑惑，什么是GIL？

热心网友回答了他：GIL就是全局解释器锁，它是导致Python中的多线程程序运行速度和单线程程序差不多的原因。

嗯......这个解释很简洁，但还是让人摸不着头脑。

Global Interpreter Lock（GIL，全局解释器锁）

那么，GIL到底是什么呢？

Python官方给出了这样一段说明：

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.)

大概的意思是，全局解释器锁（Global Interpreter Lock，简称GIL）是CPython中一个互斥锁，它能够防止多个本地线程同时执行Python字节码。

GIL是Python在设计之初为了数据安全所做的，因为CPython的内存管理不是线程安全的。

这意味着如果多个线程同时对内存进行操作，可能会导致内存分配和释放等问题，从而造成程序的不稳定或崩溃。

但因为GIL的限制，在Python多线程的情况下，每个线程的执行就变成：

获取GIL、执行代码直到sleep或者是python虚拟机将其挂起，释放GIL。

GIL成为了线程执行的通行证，没有GIL，该线程就不允许进入GPU执行。

但在一个python进程中GIL只有一个，所以必须在执行完代码后释放GIL。

而每次释放GIL锁，线程之间都会进行GIL竞争、线程切换等步骤，这大大消耗了算力资源。

因此，Python虽号称是多线程处理，但实际上和单线程处理没有区别。

在现在电脑处理器都是多核的情况下，线程1拿到GIL在CPU上进行处理时，其他线程和CPU就只能眼巴巴在一旁等着。

这也是众多开发者，多年来将Python多线程视为鸡肋，推荐大家使用多进程的主要原因。

现在没有了GIL这把「锁」，很多使用Python编写的代码将会得到效率上的飞升。

如果您希望程序运行得更快，您会选择 C/xx 吗？ 肯定是的。尽管我不会用 Python 来做操作系统，但如此多的应用程序代码是用 Python 编写的，GIL被取消其影响是巨大的。

「无GIL」Python的未来计划

在公布了Python中将弃用GIL的消息后，核心开发成员Thomas Wouters发帖讲述了对「无GIL」Python的未来展望：

原帖地址：https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474

核心开发团队将在未来几周内完善接受PEP 703在Python中的细节。

无GIL会是未来长期Python构建的唯一模式，但考虑到向后兼容性，对支持「无GIL」构建模式所需的第三方代码更改，将在带有GIL的构建模式下进行工作。

团队仍在考虑两种构建模式的ABI兼容性要求和其他细节，以及对向后兼容性的影响。

在完全切换为「无GIL」构建模式之前，需要看到社区对其的支持。不能只是将默认构建模式改为「无GIL」，然后期望社区解决所需的工作。

核心开发人员要在新的构建模式下获得经验，并处理现有代码的线程安全性。

同时要确保Python社区接受这些改变，并使改变造成的破坏性是可以接受的。

Thomas为此规划了三个阶段：

- 短期：将「无GIL」构建模式作为实验性的构建模式添加，预计在Python 3.13版本实施。需要时间来确定API设计、打包和分发等方面的需求，以使社区能够支持它。同时不鼓励分发商将实验性的「无GIL」构建模式作为默认解释器。

- 中期：在有足够社区支持以实际生产中使用「无GIL」后，将其设为支持状态，但不做默认（目标日期/Python版本仍需确定）。具体实施时间将取决于API更改的向后兼容性和社区还需做的工作量。预计这个过程可能需要一年或两年，甚至更长时间。一旦声明支持，「无GIL」可能会成为一些分发版本的默认构建模式，但这可能因Python软件包对「无GIL」的支持情况而异。

- 长期：目标是「无GIL」成为默认构建模式，并移除GIL的所有痕迹，同时尽量不破坏向后兼容性。不希望这段时间持续太久，因为同时存在两种常见构建模式可能给社区带来负担，但也不能仓促行事。预计可能需要长达五年的时间才能实现这一目标。

也许大家早就苦「GIL」久矣！现在，几乎整个社区都在期待着无GIL Python的到来。

参考资料：

https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474/10