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

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

GIL的起源

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

>>>importsys>>>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ì)遇到raceconditions(競(jìng)爭(zhēng))，為了避免raceconditions，最簡(jiǎn)單有效的辦法就是加一個(gè)互斥鎖。

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

嘗試消除GIL

CPU進(jìn)入多核時(shí)代后，可以同時(shí)做多個(gè)計(jì)算任務(wù),GIL才真正變成問題。在1999年，有個(gè)叫GregStein的大佬基于Python1.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ī)器。也就是說除去了GIL后，你使用2個(gè)CPU才能獲取比原來1個(gè)CPU稍微好一點(diǎn)的性能，這種提升明顯得不償失，GregStein的嘗試也就失敗告終。

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

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

簡(jiǎn)單。從長(zhǎng)遠(yuǎn)來看該方案必須是可實(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，目前，還沒有人滿足以上需求的同時(shí)去除GIL成功的。

積重難返

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

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

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

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

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

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

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

最后的話

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

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

以上內(nèi)容為大家介紹了Python有可能刪除GIL嗎?希望對(duì)大家有所幫助，如果想要了解更多Python相關(guān)知識(shí)，請(qǐng)關(guān)注IT培訓(xùn)機(jī)構(gòu):千鋒教育。http://www.em-kal.com/