早在今年一月份，一份關(guān)于將Python中全局解釋器鎖成為可選的PEP 703提案讓Python社區(qū)炸了鍋，這個被人詬病多年的功能成為每個Python使用者的痛點(diǎn)

就我個人而言，很多時候強(qiáng)行選擇多進(jìn)程達(dá)到目的，但多進(jìn)程間的通信又造成了較大困擾

什么是Python中的全局解釋器鎖？

簡單來說，Python 全局解釋器鎖（Global Interpreter Lock 或 GIL）是一個互斥鎖，它只允許一個線程控制 Python 解釋器

這意味著任意時刻只能有一個線程處于執(zhí)行狀態(tài)。對于執(zhí)行單線程程序的開發(fā)者來說，GIL 的影響并不明顯，但在 CPU 密集型和多線程代碼中，它可能成為性能瓶頸

由于 GIL 在多核 CPU 架構(gòu)中也只允許一個線程執(zhí)行，它在 Python 中擁有“臭名昭著”的特性

GIL的設(shè)計解決了Python什么問題？

在Python中，使用引用計數(shù)來進(jìn)行內(nèi)存管理，創(chuàng)建的對象有一個引用計數(shù)變量，用于跟蹤指向該對象的引用數(shù)量。當(dāng)該計數(shù)達(dá)到零時，該對象占用的內(nèi)存被釋放

但是，引用計數(shù)需要防止競爭，即兩個線程同時增加或減少其值。如果發(fā)生這種情況，可能會導(dǎo)致內(nèi)存泄漏而永遠(yuǎn)不會釋放，或者更糟糕的是，該對象的引用仍然存在時錯誤地釋放內(nèi)存，可能會導(dǎo)致 Python 程序崩潰或出現(xiàn)其他“奇怪”的錯誤

這個引用計數(shù)變量可以通過為所有在線程之間共享的數(shù)據(jù)結(jié)構(gòu)添加鎖來確保安全，從而避免不一致的修改

但是，為每個對象或一組對象添加鎖意味著會存在多個鎖，這可能會導(dǎo)致一個問題——死鎖（只有在存在多個鎖時才會發(fā)生死鎖）。另一個副作用是由于重復(fù)獲取和釋放鎖而導(dǎo)致的性能下降

GIL 是對解釋器本身的單一鎖，它增加了一個規(guī)則，即執(zhí)行任何 Python 字節(jié)碼都需要獲取解釋器鎖。這樣可以防止死鎖（因?yàn)橹挥幸粋€鎖），并且不會引入太多性能開銷。但是，它實(shí)際上使得任何 CPU 密集型的 Python 程序都變成了單線程執(zhí)行

了解以上背景后，可以清楚PEP 703提案的目的：

GIL 確實(shí)是并發(fā)編程的主要障礙。對于科學(xué)計算任務(wù)而言，這種缺乏并發(fā)性通常比 Python 代碼執(zhí)行速度更為嚴(yán)重，因?yàn)榇蟛糠痔幚砥髦芷诙蓟ㄙM(fèi)在優(yōu)化的 CPU 或 GPU 內(nèi)核中。GIL 引入了一個全局瓶頸，如果其他線程調(diào)用任何 Python 代碼，可能會阻止它們?nèi)〉眠M(jìn)展。目前在 CPython 中有一些現(xiàn)有方法可以實(shí)現(xiàn)并行性，但這些技術(shù)都存在重要限制。

PEP 703提議做出什么修改？

PEP 提議向 CPython 添加一個構(gòu)建配置選項(xiàng)（--disable-gil），以便讓它在沒有全局解釋器鎖的情況下運(yùn)行 Python 代碼，并對解釋器進(jìn)行必要的更改以實(shí)現(xiàn)線程安全性。

而這份提案也在最近有了最新進(jìn)展

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

CPython核心開發(fā)者@Thomas Wouters代表Python指導(dǎo)委員會指出，關(guān)于PEP 703提案的民意調(diào)查情況來看整體是持積極態(tài)度，而Python指導(dǎo)委員會也計劃接受提案，目前正在努力研究相關(guān)細(xì)節(jié)，他們將未來方向分為三個階段：

短期來看，計劃在 3.13 版本（如果延后到 3.14，也沒關(guān)系）中將no-GIL的構(gòu)建作為實(shí)驗(yàn)性構(gòu)建模式加入進(jìn)來。我們希望將這個構(gòu)建模式標(biāo)記為實(shí)驗(yàn)性，以明確表明雖然核心開發(fā)人員支持該構(gòu)建模式，但不能指望社區(qū)立刻全力支持它

我們需要時間來弄清楚我們需要做些什么，至少在API設(shè)計、打包和分發(fā)方面，以便讓社區(qū)支持它。另外，我們也希望制止發(fā)行者將實(shí)驗(yàn)性的no-GIL的構(gòu)建作為默認(rèn)解釋器發(fā)布

中期，一旦我們確信社區(qū)有足夠的支持來實(shí)際應(yīng)用no-GIL的構(gòu)建，我們將將其設(shè)為受支持但暫不設(shè)為默認(rèn)（目前）。然后，我們會設(shè)定一個目標(biāo)日期或Python版本來將其設(shè)為默認(rèn)

具體時間將取決于很多因素，比如API的向后兼容性如何（例如穩(wěn)定ABI的處理方式），以及社區(qū)認(rèn)為還需要做多少工作。我們預(yù)計這可能需要至少一兩年，甚至更長時間。一旦宣布支持，我們預(yù)計一些發(fā)行者可能會開始默認(rèn)發(fā)布no-GIL的版本，不過這可能會受到其他Python包是否支持no-GIL的影響而有很大差異

從長期來看，我們希望no-GIL成為默認(rèn)設(shè)置，并且移除GIL的所有痕跡（同時盡量不破壞向后兼容性）。我們不希望等得太久，因?yàn)閾碛袃煞N常見的構(gòu)建方式可能會對社區(qū)造成較大負(fù)擔(dān)（例如可能會加倍測試資源和調(diào)試場景），但我們也不能倉促行事。我們認(rèn)為這可能需要長達(dá)五年的時間來實(shí)現(xiàn)

關(guān)于更多PEP 703提案的細(xì)節(jié)可以參考如下網(wǎng)頁，更詳細(xì)的列舉了GIL如何影響人工智能方向的科研人員

https://peps.python.org/pep-0703/

總的來說，如果該提案被正式發(fā)布，那么Python可能又將迎來一個大更新，值得期待

以上就是本期全部內(nèi)容，我是啥都生，下次再見