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

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

GIL的起源

Python第一次發(fā)布是在1991年，當(dāng)時(shí)的CPU都是單核，單核中，多線(xiàn)程主要為了一邊做IO，一邊做CPU計(jì)算而設(shè)計(jì)的，Python編譯器是由C語(yǔ)言編寫(xiě)的，因此也叫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)存了，比如：

>>>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è)線(xiàn)程引用了data，那么引用計(jì)數(shù)再增加1，如果某個(gè)線(xiàn)程使用了data后運(yùn)行結(jié)束，那么引用計(jì)數(shù)就減少1，多線(xiàn)程對(duì)同一個(gè)變量「引用計(jì)數(shù)」進(jìn)行修改，就會(huì)遇到raceconditions(競(jìng)爭(zhēng))，為了避免raceconditions，最簡(jiǎn)單有效的辦法就是加一個(gè)互斥鎖。

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

嘗試消除GIL

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

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

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

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

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

速度。去除GIL不能降低單線(xiàn)程的性能。

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

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

及時(shí)銷(xiāo)毀不可達(dá)對(duì)象，回收內(nèi)存。

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

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

積重難返

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

還有一個(gè)很明顯的例子，Python解釋器不止有CPython，還有用Java編寫(xiě)的Python，.NET實(shí)現(xiàn)的IronPython，這些解釋器完全沒(méi)有GIL，可是有多少人為它們編寫(xiě)擴(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ò)展，然后需要更新和移植更改以配合Python3，這也是Python3一開(kāi)始不被社區(qū)所接受的原因。

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

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

最后的話(huà)

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

不過(guò)不必沮喪，GIL影響的也僅僅是多線(xiàn)程執(zhí)行計(jì)算密集型的任務(wù)罷了，這種場(chǎng)景大多數(shù)程序員都很少遇到，即使有，可以使用多進(jìn)程來(lái)避免GIL的影響，或者使用其他編程語(yǔ)言實(shí)現(xiàn)，任何編程語(yǔ)言或技術(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://m.2667701.com/