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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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