如果 Python 4.0 摆脱了 GIL…( 四 ) _Python

返回这个对象的地址

这一切在 GIL 的保护下没什么问题。然鹅现在我们没有 GIL 了，这里会出现一个问题：当有一个线程执行写操作时，在步骤 2 把这个对象释放掉了（Reference Count 减少到 0），而这个时候又有一个线程已经完成了步骤 1 ，开始直接步骤 2 时，就崩溃了，因为这个对象已经被释放掉了。
Sam 的设计是，既然我们没有 GIL 这把全局锁了，我们就要给单个对象加局部锁，不过我们只对写操作加锁。具体实现简单来说就是增加了 Reference Counting 版本控制和更多的检查判断并重试机制，比如在执行上述的步骤 2 时首先检查对象是否 Reference Count 已经为 0 了，如果是的话，从步骤 1 开始重试（重试之后我理解就可以读到一个新的地址或是可以识别出是空地址从而保证安全性）。
目前对于 list 和 dict 的重新设计，主要是对单线程处理速度进行了优化，对于多线程处理只能保证安全而速度上有一定程度的牺牲。也许以后会出现一些特殊的 collection 类型，以应对那种多线程频繁调用的情况。
Python 4.0 是否真的会移除GIL？
我个人感觉，出现一个没有GIL版本的 Python 4.0 的可能性是比较大的，毕竟 CPython 核心团队其实已经在着手将 Sam 大神的 nogil 项目合入 Python 3.11 了，而且该项目的性能分数已经达到甚至部分超过了 Guido 爸爸之前对于拿掉 GIL 的基本条件，这一次没有“借口”可以拒绝了。当然 Python 3.11 多半不会是一个无 GIL 版本， nogil 项目无论多强大它也还只是个实验项目，其仍存在诸多大小问题，以及很多仍待讨论的架构决策，都不是一个小版本就能够解决掉的。
至于 Python 4.0 ，它自己本身就是个未知数。核心团队自己已经重申了多次他们想尽量延后 Python 4.0 的时间，因为 Python 2.0 到 3.0 大家已经很伤了，这么快又搞一波怕大家心里承受不了。。。Guido 爸爸很久就曾发推解释过一次：

文章插图

这里我想吐槽一下，从 Python 3.5 开始，每个版本就已经很伤了好么还不如赶紧上 nogil 也算是个痛并快乐着。
无论结果如何，我作为一个被 Python 领进门的、被 Python 各种骚操作种草的、到现在不管后端服务还是客户端脚本还是各种AI“小研究”都首选 Python的忠实粉丝，衷心祝愿 Python 未来...越来越妖！

【如果 Python 4.0 摆脱了 GIL…】