我們知道,在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/