我們知道，在 CPython 中，有一個(gè)全局解釋器鎖，英文叫 global interpreter lock，簡(jiǎn)稱 GIL，是一個(gè)互斥鎖，用來(lái)保護(hù) Python 世界里的對(duì)象，防止同一時(shí)刻多個(gè)線程執(zhí)行 Python 的字節(jié)碼，從而確保線程安全，這導(dǎo)致了 Python 的線程無(wú)法利用多核 CPU 的優(yōu)勢(shì)，因此有人說(shuō) Python 的多線程是偽多線程，性能不高，那么 Python 將來(lái)有可能去除 GIL 嗎？

要回答這個(gè)問(wèn)題，先從 GIL 的起源進(jìn)行分析。

GIL 的起源

Python 第一次發(fā)布是在 1991 年，當(dāng)時(shí)的 CPU 都是單核，單核中，多線程主要為了一邊做IO，一邊做 CPU 計(jì)算而設(shè)計(jì)的，Python 編譯器是由 C 語(yǔ)言編寫的，因此也叫 CPython，那時(shí)候很多編程語(yǔ)言沒(méi)有自動(dòng)內(nèi)存管理的功能，為了實(shí)現(xiàn)自動(dòng)垃圾回收，Python 為每一個(gè)對(duì)象進(jìn)行了引用計(jì)數(shù)，當(dāng)引用計(jì)數(shù)為 0 的時(shí)候說(shuō)明該對(duì)象可以回收，從而釋放內(nèi)存了，比如：

>>> import sys>>> data = { ’gzh’: ’Python七號(hào)’}>>> var1 = data>>> sys.getrefcount(data)3>>>

這里 data 對(duì)象就有 3 個(gè)引用， 一個(gè)是本身，一個(gè)是變量 var1，一個(gè)是 getrefcount 函數(shù)的參數(shù)，如果此時(shí)又有一個(gè)線程引用了 data，那么引用計(jì)數(shù)再增加 1，如果某個(gè)線程使用了 data 后運(yùn)行結(jié)束，那么引用計(jì)數(shù)就減少 1，多線程對(duì)同一個(gè)變量「引用計(jì)數(shù)」進(jìn)行修改，就會(huì)遇到 race conditions（競(jìng)爭(zhēng)），為了避免 race conditions，最簡(jiǎn)單有效的辦法就是加一個(gè)互斥鎖。

如果對(duì)每一個(gè)對(duì)象都加鎖，有可能引發(fā)另一個(gè)問(wèn)題，就是死鎖，而且頻繁的獲取和釋放會(huì)導(dǎo)致性能下降，最簡(jiǎn)單有效的方法就是加一個(gè)解釋器鎖，線程在執(zhí)行任何字節(jié)碼時(shí)都先獲取解釋器鎖，這就避免了死鎖，而且不會(huì)有太多的性能消耗。當(dāng)時(shí) CPU 都是單核，而且這種 GIL 設(shè)計(jì)簡(jiǎn)單，并不會(huì)影響性能，因此一直沿用至今天。GIL 存在最主要的原因，就是因?yàn)?Python 的內(nèi)存管理不是線程安全的，這就是 GIL 產(chǎn)生并存在的主要緣由。

嘗試消除 GIL

CPU 進(jìn)入多核時(shí)代后，可以同時(shí)做多個(gè)計(jì)算任務(wù), GIL 才真正變成問(wèn)題。在 1999 年，有個(gè)叫 Greg Stein 的大佬基于 Python 1.5 版本消除了 GIL，取代代之的是在可變數(shù)據(jù)結(jié)構(gòu)上加上更細(xì)粒度的鎖，也提交了補(bǔ)丁用于去除對(duì)全局可變對(duì)象的依賴，然后在標(biāo)準(zhǔn)測(cè)試時(shí)表明去除 GIL 后單線程比不去除時(shí)慢了近 2 倍，測(cè)試的機(jī)器還是當(dāng)時(shí)性能最好 Windows 機(jī)器。也就是說(shuō)除去了 GIL 后，你使用 2 個(gè) CPU 才能獲取比原來(lái) 1 個(gè) CPU 稍微好一點(diǎn)的性能，這種提升明顯得不償失，Greg Stein 的嘗試也就失敗告終。

Python 之父 Guido van Rossum 也歡迎社區(qū)的志愿者去嘗試去除 GIL，只要不降低單線程的性能，但他也提到，去掉 GIL 不是一件容易的事。

Python 開(kāi)發(fā)者郵件列表中也偶爾會(huì)有去除 GIL 的議題，但是以下需求必須滿足：

簡(jiǎn)單。從長(zhǎng)遠(yuǎn)來(lái)看該方案必須是可實(shí)施、可維護(hù)的。 并發(fā)。去除 GIL 必須能提升多線程的性能。 速度。去除 GIL 不能降低單線程的性能。 滿足 CPython 的特性。該方案必須支持 CPython 的功能，比如 __del__ 和弱引用。 API 的兼容性。該方案應(yīng)與所有現(xiàn)有CPython擴(kuò)展使用的宏在源方面兼容。 及時(shí)銷毀不可達(dá)對(duì)象，回收內(nèi)存。 有序銷毀，比如不可達(dá)對(duì)象 X 引用了 A，那么應(yīng)該在銷毀 A 之前先銷毀 X（有些垃圾回收算法并不能做到這一點(diǎn)）。

有些需求不容易被滿足，比如 4，5，7，目前，還沒(méi)有人滿足以上需求的同時(shí)去除 GIL 成功的。

積重難返

這些年 Python 實(shí)在太火了，很多優(yōu)秀的庫(kù)都是基于 CPython 進(jìn)行編寫的，很多都是 90 年代的 C 擴(kuò)展庫(kù)，如果要除去 GIL，那么很多基于 GIL 編寫的 C 擴(kuò)展便無(wú)法使用，也就是去了 GIL，Python 生態(tài)有很多擴(kuò)展或三方庫(kù)者無(wú)法使用。

還有一個(gè)很明顯的例子，Python 解釋器不止有 CPython，還有用 Java 編寫的 Python，.NET 實(shí)現(xiàn)的 IronPython，這些解釋器完全沒(méi)有 GIL，可是有多少人為它們編寫擴(kuò)展呢？

Python 之所以如此火爆，與它有著豐富的三方庫(kù)開(kāi)箱即用有著很大的關(guān)系，積重難返，去除 GIL 很困難。

為什么 Python3 一開(kāi)始時(shí)不去除 GIL

Python3 在最開(kāi)始時(shí)是有機(jī)會(huì)實(shí)現(xiàn)很多新功能，在此過(guò)程中，打破了一些現(xiàn)有的 C 擴(kuò)展，然后需要更新和移植更改以配合 Python 3，這也是 Python3 一開(kāi)始不被社區(qū)所接受的原因。

與 Python2 相比，刪除 GIL 將使 Python3 在單線程性能方面更慢，而且很多優(yōu)秀的擴(kuò)展將不能再使用，如果真的這樣，可以想象 Python3 不可能有未來(lái)，最終的結(jié)果是 Python3 仍然保持有 GIL。

但 Python3 也為現(xiàn)有的 GIL 帶來(lái)了重大改進(jìn)，在 Python 3.2 版本中，確保了計(jì)算密集型線程和 I/O 密集型線程并存時(shí)， I/O 密集型長(zhǎng)期獲取不到 GIL 而無(wú)法執(zhí)行的問(wèn)題，提升了多線程的性能。

最后的話

Python 因?yàn)閮?nèi)存管理不是線程安全的，因此自出生起就自帶 GIL，然后很多擴(kuò)展都是在 GIL 的保護(hù)下編寫的，時(shí)間一長(zhǎng)積重難反，Python3 一開(kāi)始也因去除 GIL 導(dǎo)致單線程性能下降的問(wèn)題而保留 GIL，現(xiàn)在已經(jīng)是 Python3.9 版本了，將來(lái) Python 去除 GIL 的可能性微乎其微，換句話說(shuō)，去除 GIL 的 Python 也就不是我們認(rèn)識(shí)的 Python 了。

不過(guò)不必沮喪，GIL 影響的也僅僅是多線程執(zhí)行計(jì)算密集型的任務(wù)罷了，這種場(chǎng)景大多數(shù)程序員都很少遇到，即使有，可以使用多進(jìn)程來(lái)避免 GIL 的影響，或者使用其他編程語(yǔ)言實(shí)現(xiàn)，任何編程語(yǔ)言或技術(shù)都不是十全十美的，發(fā)揮所長(zhǎng)是最重要的，即使有 GIL，我也不在乎，也會(huì)依然使用 Python。

以上就是Python 有可能刪除 GIL 嗎？的詳細(xì)內(nèi)容，更多關(guān)于Python 刪除 GIL 的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！