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

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

GIL的起源

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

>>>importsys>>>data={'gzh':'Python七號'}>>>var1=data>>>sys.getrefcount(data)3>>>

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

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

嘗試消除GIL

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

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

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

簡單。從長遠(yuǎn)來看該方案必須是可實(shí)施、可維護(hù)的。

并發(fā)。去除GIL必須能提升多線程的性能。

速度。去除GIL不能降低單線程的性能。

滿足CPython的特性。該方案必須支持CPython的功能，比如__del__和弱引用。

API的兼容性。該方案應(yīng)與所有現(xiàn)有CPython擴(kuò)展使用的宏在源方面兼容。

及時銷毀不可達(dá)對象，回收內(nèi)存。

有序銷毀，比如不可達(dá)對象X引用了A，那么應(yīng)該在銷毀A之前先銷毀X(有些垃圾回收算法并不能做到這一點(diǎn))。

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

積重難返

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

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

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

為什么Python3一開始時不去除GIL

Python3在最開始時是有機(jī)會實(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密集型線程并存時，I/O密集型長期獲取不到GIL而無法執(zhí)行的問題，提升了多線程的性能。

最后的話

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

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

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