超過十年以上，沒有比解釋器全局鎖（GIL）讓Python新手和專家更有挫折感或者更有好奇心。

未解決的問題

隨處都是問題。難度大、耗時(shí)多肯定是其中一個(gè)問題。僅僅是嘗試解決這個(gè)問題就會(huì)讓人驚訝。之前是整個(gè)社區(qū)的嘗試，但現(xiàn)在只是外圍的開發(fā)人員在努力。對(duì)于新手，去嘗試解決這樣的問題，主要是因?yàn)閱栴}難度足夠大，解決之后可以獲得相當(dāng)?shù)臉s譽(yù)。計(jì)算機(jī)科學(xué)中未解決的 P = NP 就是這樣的問題。對(duì)此如果能給出多項(xiàng)式時(shí)間復(fù)雜度的答案，那簡直就可以改變世界了。Python最困難的問題比證明P = NP要容易一些，不過迄今仍然沒有一個(gè)滿意的解決，要知道，這個(gè)問題的實(shí)用的解決方案同樣能起著變革性的作用。正因?yàn)槿绱耍苋菀卓吹絇ython社區(qū)會(huì)有如此多的人關(guān)注于這樣的問題: “對(duì)于解釋器全局鎖能做什么?”

Python的底層

要理解GIL的含義，我們需要從Python的基礎(chǔ)講起。像C++這樣的語言是編譯型語言，所謂編譯型語言，是指程序輸入到編譯器，編譯器再根據(jù)語言的語法進(jìn)行解析，然后翻譯成語言獨(dú)立的中間表示，最終鏈接成具有高度優(yōu)化的機(jī)器碼的可執(zhí)行程序。編譯器之所以可以深層次的對(duì)代碼進(jìn)行優(yōu)化，是因?yàn)樗梢钥吹秸麄€(gè)程序（或者一大塊獨(dú)立的部分）。這使得它可以對(duì)不同的語言指令之間的交互進(jìn)行推理，從而給出更有效的優(yōu)化手段。

與此相反，Python是解釋型語言。程序被輸入到解釋器來運(yùn)行。解釋器在程序執(zhí)行之前對(duì)其并不了解；它所知道的只是Python的規(guī)則，以及在執(zhí)行過程中怎樣去動(dòng)態(tài)的應(yīng)用這些規(guī)則。它也有一些優(yōu)化，但是這基本上只是另一個(gè)級(jí)別的優(yōu)化。由于解釋器沒法很好的對(duì)程序進(jìn)行推導(dǎo)，Python的大部分優(yōu)化其實(shí)是解釋器自身的優(yōu)化。更快的解釋器自然意味著程序的運(yùn)行也能“免費(fèi)”的更快。也就是說，解釋器優(yōu)化后，Python程序不用做修改就可以享受優(yōu)化后的好處。

這一點(diǎn)很重要，讓我們?cè)購?qiáng)調(diào)一下。如果其他條件不變，Python程序的執(zhí)行速度直接與解釋器的“速度”相關(guān)。不管你怎樣優(yōu)化自己的程序，你的程序的執(zhí)行速度還是依賴于解釋器執(zhí)行你的程序的效率。這就很明顯的解釋了為什么我們需要對(duì)優(yōu)化Python解釋器做這么多的工作了。對(duì)于Python程序員來說，這恐怕是與免費(fèi)午餐最接近的了。

免費(fèi)午餐結(jié)束了

還是沒有結(jié)束？摩爾定律給出了硬件速度會(huì)按照確定的時(shí)間周期增長，與此同時(shí)，整整一代程序員學(xué)會(huì)了如何編碼。如果一個(gè)人寫了比較慢的代碼，最簡單的結(jié)果通常是更快的處理器去等待代碼的執(zhí)行。顯然，摩爾定律仍然是正確的，并且還會(huì)在很長一段時(shí)間生效，不過它提及的方式有了根本的變化。并非是時(shí)鐘頻率增長到一個(gè)高不可攀的速度，而是通過多核來利用晶體管密度提高帶來的好處。在新處理器上運(yùn)行的程序要想充分利用其性能，必須按照并發(fā)方式進(jìn)行重寫。

大部分開發(fā)者聽到“并發(fā)”通常會(huì)立刻想到多線程的程序。目前來說，多線程執(zhí)行還是利用多核系統(tǒng)最常用的方式。盡管多線程編程大大好于“順序”編程，不過即便是仔細(xì)的程序員也沒法在代碼中將并發(fā)性做到最好。編程語言在這方面應(yīng)該做的更好，大部分應(yīng)用廣泛的現(xiàn)代編程語言都會(huì)支持多線程編程。

意外的事實(shí)

現(xiàn)在我們來看一下問題的癥結(jié)所在。要想利用多核系統(tǒng)，Python必須支持多線程運(yùn)行。作為解釋型語言，Python的解釋器必須做到既安全又高效。我們都知道多線程編程會(huì)遇到的問題。解釋器要留意的是避免在不同的線程操作內(nèi)部共享的數(shù)據(jù)。同時(shí)它還要保證在管理用戶線程時(shí)保證總是有最大化的計(jì)算資源。

那么，不同線程同時(shí)訪問時(shí)，數(shù)據(jù)的保護(hù)機(jī)制是怎樣的呢？答案是解釋器全局鎖。從名字上看能告訴我們很多東西，很顯然，這是一個(gè)加在解釋器上的全局（從解釋器的角度看）鎖（從互斥或者類似角度看）。這種方式當(dāng)然很安全，但是它有一層隱含的意思（Python初學(xué)者需要了解這個(gè)）：對(duì)于任何Python程序，不管有多少的處理器，任何時(shí)候都總是只有一個(gè)線程在執(zhí)行。

許多人都是偶然發(fā)現(xiàn)這個(gè)事實(shí)的。網(wǎng)上的很多討論組和留言板都充斥著來自Python初學(xué)者和專家的類似這樣的問題——”為什么我全新的多線程Python程序運(yùn)行得比其只有一個(gè)線程的時(shí)候還要慢？“許多人在問這個(gè)問題時(shí)還是非常犯暈的，因?yàn)轱@然一個(gè)具有兩個(gè)線程的程序要比其只有一個(gè)線程時(shí)要快（假設(shè)該程序確實(shí)是可并行的）。事實(shí)上，這個(gè)問題被問得如此頻繁以至于Python的專家們精心制作了一個(gè)標(biāo)準(zhǔn)答案：”不要使用多線程，請(qǐng)使用多進(jìn)程。“但這個(gè)答案比那個(gè)問題更加讓人困惑。難道我不能在Python中使用多線程？在Python這樣流行的一個(gè)語言中使用多線程究竟是有多糟糕，連專家都建議不要使用。難道我真的漏掉了一些東西？

很遺憾，沒有任何東西被漏掉。由于Python解釋器的設(shè)計(jì)，使用多線程以提高性能應(yīng)該算是一個(gè)困難的任務(wù)。在最壞的情況下，它將會(huì)降低（有時(shí)很明顯）你的程序的運(yùn)行速度。一個(gè)計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)的大學(xué)生新手可能會(huì)告訴你當(dāng)多個(gè)線程都在競爭一個(gè)共享資源時(shí)將會(huì)發(fā)生什么。結(jié)果通常不會(huì)非常理想。很多情況下多線程都能很好地工作，可能對(duì)于解釋器的實(shí)現(xiàn)和內(nèi)核開發(fā)人員來說，沒有關(guān)于Python多線程性能的過多抱怨。

現(xiàn)在該怎么辦？驚慌？

那么，這又能怎樣？問題解決了嗎？難道我們作為Python開發(fā)人員就意味著要放棄使用多線程來探索并行的想法了？為什么無論怎樣，GIL需要保證只有一個(gè)線程在某一時(shí)刻處于運(yùn)行中？難道不可以添加細(xì)粒度的鎖來阻止多個(gè)獨(dú)立對(duì)象的同時(shí)訪問？并且為什么之前沒有人去嘗試過類似的事情？

這些實(shí)用的問題有著十分有趣的回答。GIL對(duì)諸如當(dāng)前線程狀態(tài)和為垃圾回收而用的堆分配對(duì)象這樣的東西的訪問提供著保護(hù)。然而，這對(duì)Python語言來說沒什么特殊的，它需要使用一個(gè)GIL。這是該實(shí)現(xiàn)的一種典型產(chǎn)物?，F(xiàn)在也有其它的Python解釋器（和編譯器）并不使用GIL。雖然，對(duì)于CPython來說，自其出現(xiàn)以來已經(jīng)有很多不使用GIL的解釋器。

那么為什么不拋棄GIL呢？許多人也許不知道，在1999年，針對(duì)Python 1.5，一個(gè)經(jīng)常被提到但卻不怎么理解的“free threading”補(bǔ)丁已經(jīng)嘗試實(shí)現(xiàn)了這個(gè)想法，該補(bǔ)丁來自Greg Stein。在這個(gè)補(bǔ)丁中，GIL被完全的移除，且用細(xì)粒度的鎖來代替。然而，GIL的移除給單線程程序的執(zhí)行速度帶來了一定的代價(jià)。當(dāng)用單線程執(zhí)行時(shí)，速度大約降低了40%。使用兩個(gè)線程展示出了在速度上的提高，但除了這個(gè)提高，這個(gè)收益并沒有隨著核數(shù)的增加而線性增長。由于執(zhí)行速度的降低，這一補(bǔ)丁被拒絕了，并且?guī)缀醣蝗诉z忘。

移除GIL非常困難，讓我們?nèi)ベ徫锇桑?/p>

（譯者注：XXX is hard. Let’s go shopping!在英語中類似于中文的咆哮體。其隱含意思為想成功完成某件事情非常困難，我們?nèi)ブ苯訉ふ业谌降漠a(chǎn)品替代吧。）

不過，“free threading”這個(gè)補(bǔ)丁是有啟發(fā)性意義的，其證明了一個(gè)關(guān)于Python解釋器的基本要點(diǎn)：移除GIL是非常困難的。由于該補(bǔ)丁發(fā)布時(shí)所處的年代，解釋器變得依賴更多的全局狀態(tài)，這使得想要移除當(dāng)今的GIL變得更加困難。值得一提的是，也正是因?yàn)檫@個(gè)原因，許多人對(duì)于嘗試移除GIL變得更加有興趣。困難的問題往往很有趣。

但是這可能有點(diǎn)被誤導(dǎo)了。讓我們考慮一下：如果我們有了一個(gè)神奇的補(bǔ)丁，其移除了GIL，并且沒有對(duì)單線程的Python代碼產(chǎn)生性能上的下降，那么什么事情將會(huì)發(fā)生？我們將會(huì)獲得我們一直想要的：一個(gè)線程API可能會(huì)同時(shí)利用所有的處理器。那么現(xiàn)在，我們已經(jīng)獲得了我們希望的，但這確實(shí)是一個(gè)好事嗎？

基于線程的編程毫無疑問是困難的。每當(dāng)某個(gè)人覺得他了解關(guān)于線程是如何工作的一切的時(shí)候，總是會(huì)悄無聲息的出現(xiàn)一些新的問題。因?yàn)樵谶@方面想要得到正確合理的一致性真的是太難了，因此有一些非常知名的語言設(shè)計(jì)者和研究者已經(jīng)總結(jié)得出了一些線程模型。就像某個(gè)寫過多線程應(yīng)用的人可以告訴你的一樣，不管是多線程應(yīng)用的開發(fā)還是調(diào)試都會(huì)比單線程的應(yīng)用難上數(shù)倍。程序員通常所具有的順序執(zhí)行的思維模恰恰就是與并行執(zhí)行模式不相匹配。GIL的出現(xiàn)無意中幫助了開發(fā)者免于陷入困境。在使用多線程時(shí)仍然需要同步原語的情況下，GIL事實(shí)上幫助我們保持不同線程之間的數(shù)據(jù)一致性問題。

那么現(xiàn)在看起來討論P(yáng)ython最難得問題是有點(diǎn)問錯(cuò)了問題。我們有非常好的理由來說明為什么Python專家推薦我們使用多進(jìn)程代替多線程，而不是去試圖隱藏Python線程實(shí)現(xiàn)的不足。更進(jìn)一步，我們鼓勵(lì)開發(fā)者使用更安全更直接的方式實(shí)現(xiàn)并發(fā)模型，同時(shí)保留使用多線程進(jìn)行開發(fā)除非你覺的真的非常必要的話。對(duì)于大多數(shù)人來說什么是最好的并行編程模型可能并不是十分清楚。但是目前我們清楚的是多線程的方式可能并不是最好的。

至于GIL，不要認(rèn)為它在那的存在就是靜態(tài)的和未經(jīng)分析過的。Antoine Pitrou 在Python 3.2中實(shí)現(xiàn)了一個(gè)新的GIL，并且?guī)е恍┓e極的結(jié)果。這是自1992年以來，GIL的一次最主要改變。這個(gè)改變非常巨大，很難在這里解釋清楚，但是從一個(gè)更高層次的角度來說，舊的GIL通過對(duì)Python指令進(jìn)行計(jì)數(shù)來確定何時(shí)放棄GIL。這樣做的結(jié)果就是，單條Python指令將會(huì)包含大量的工作，即它們并沒有被1:1的翻譯成機(jī)器指令。在新的GIL實(shí)現(xiàn)中，用一個(gè)固定的超時(shí)時(shí)間來指示當(dāng)前的線程以放棄這個(gè)鎖。在當(dāng)前線程保持這個(gè)鎖，且當(dāng)?shù)诙€(gè)線程請(qǐng)求這個(gè)鎖的時(shí)候，當(dāng)前線程就會(huì)在5ms后被強(qiáng)制釋放掉這個(gè)鎖（這就是說，當(dāng)前線程每5ms就要檢查其是否需要釋放這個(gè)鎖）。當(dāng)任務(wù)是可行的時(shí)候，這會(huì)使得線程間的切換更加可預(yù)測。

然而，這并不是一個(gè)完美的改變。對(duì)于在各種類型的任務(wù)上有效利用GIL這個(gè)領(lǐng)域里，最活躍的研究者可能就是David Beazley了。除了對(duì)Python 3.2之前的GIL研究最深入，他還研究了這個(gè)最新的GIL實(shí)現(xiàn)，并且發(fā)現(xiàn)了很多有趣的程序方案。對(duì)于這些程序，即使是新的GIL實(shí)現(xiàn)，其表現(xiàn)也相當(dāng)糟糕。他目前仍然通過一些實(shí)際的研究和發(fā)布一些實(shí)驗(yàn)結(jié)果來引領(lǐng)并推進(jìn)著有關(guān)GIL的討論。

不管某一個(gè)人對(duì)Python的GIL感覺如何，它仍然是Python語言里最困難的技術(shù)挑戰(zhàn)。想要理解它的實(shí)現(xiàn)需要對(duì)操作系統(tǒng)設(shè)計(jì)、多線程編程、C語言、解釋器設(shè)計(jì)和CPython解釋器的實(shí)現(xiàn)有著非常徹底的理解。單是這些所需準(zhǔn)備的就妨礙了很多開發(fā)者去更徹底的研究GIL。雖然如此，并沒有跡象表明GIL在不久以后的任何一段時(shí)間內(nèi)會(huì)遠(yuǎn)離我們。目前，它將繼續(xù)給那些新接觸Python，并且與此同時(shí)又對(duì)解決非常困難的技術(shù)問題感興趣的人帶來困惑和驚喜。

以上內(nèi)容是基于我目前對(duì)Python解釋器所做出的研究而寫。雖然我還希望寫一些有關(guān)解釋器的其它方面內(nèi)容，但是沒有任何一個(gè)比全局解釋器鎖（GIL）更為人所知。雖然我認(rèn)為這里有些內(nèi)容是不準(zhǔn)確的，但是這些技術(shù)上的細(xì)節(jié)與CPython的很多資源條目是不同的。如果你發(fā)現(xiàn)了不準(zhǔn)確的內(nèi)容，請(qǐng)及時(shí)告知我，這樣我就會(huì)盡快對(duì)其進(jìn)行改正。